** 백업 -- 데이터복구의 마지노선이다.
	  자주해 준 만큼 복구할 수 있는 데이터는 많아질것이다.
	  그리고 특정시간까지 복구도 가능하고, 다른 컴에 복사판
                데이터베이스를 만들수도(Log Shipping) 있다.

* 백업은 방식에 따라 풀, 디퍼런셜, 로그백업......그외에
		파일백업, 파일그룹백업, 다중백업등으로 나눈다.

* 풀백업

Backup database backtest to disk='e:\backup.bak'

간단하다....
Backup Database 백업할DB명 to Disk/Tape='경로'

--> 문제는 그럼 계속 백업할 때 말다 파일 이름을 계속 적을것인가?
같은 파일을 계속 추가해서 백업할 것이라면 덤프미디어를 만들어
주면 된다.

sp_addumpdevice 'disk','testbackup','e:\backup.bak'
                  디바이스타입, 디바이스이름,  디바이스경로 
backup database backtest to testbackup
backtest라는 디비를 testbackup이라는 디바이스에백업하라.
create database backtest

* 복구

drop database backtest

Restore database backtest2 from testbackup

backtest란 데이터베이스를 지우고 백업 미디어에서 backtest2란
이름으로 데이터베이스를 복구시켰다
백업구문에서 backup->restore, to->from만 다를 뿐이고,
풀백업은 이게 끝

** 디퍼런셜 백업
디퍼런셜 백업은 풀백업이 한번 실행되고 난 후에 가능하다.
이유는 디퍼러셜 백업은 풀백업 이후에 변경된 데이터만 백업을
하기 때문이다.
(곧, 데이터만 해당된다는 것이고 테이블 생성등 구조변경을 하는 
 작업은 백업되지 않는다는 말이겟지?)

Create database test

Create table test(id int)

insert into test values(1)


sp_addumpdevice 'disk','testbackup1','e:\backup1.bak'
backup database test to testbackup1

insert into test values(2)

backup database test to testbackup with differential

** 디퍼런셜 백업 복구

Use pubs
go
Drop database test

restore database test from testbackup1

select * from test..test

결과를 보니 2라는 데이터는 없다.....
이 미디어에는 지금 첫번째로 풀백업 내용이 들어있고,
두번째로 디퍼런셜 백업 내용이 들어가 있는데 첫번째 것인 풀백업
내용만 복구됬다. 자...그럼 디퍼런셜 백업내용도 복구를 해보자

use pubs
go
Drop database test

Restore database test from testbackup1 with file=1,norecovery
go
Restore database test from testbackup1 with file=2,recovery

첫번째는 리스토어를 하되 norecovry옵션도 같이 사용해서 뒤에 
더 리스토어할께 있다고 알려주고, 
두번째로 디퍼런셜 백업을 한것을 리스토어 하는데 이게 마지막
이므로 recovery옵션을 사용하여 정상 복구시켜준다

select * from test..test

여러 백업내용을 복구할 때는 꼭 위의 방식대로 사용해야 한다.
참고로 여기에 또 디퍼런셜 백업을 할 경우 복구는?
첫번째 풀백업과 세번째 디퍼런셜 백업만 복구하면 된다.
디퍼런셜 백업을 무조건 풀백업을 기준으로 하기 때문에 세번째
디퍼런셜 백업은 두번째 디퍼런셜 백업의 내용도 같이 가지고 있다

** 로그백업

풀백업과 디퍼런셜 백업만 하는 경우는 백업의 간격이 클 수 밖에 없다
풀백업은 디비 전체를 백업하므로 당연히 클 것이고,
디퍼런셜 백업도 풀백업 기준에서 멀어지면 백업의 양은 커진다.

백업량이 많으면 당연히 백업 시간이 증가하고 자주 못하게 된다.
복구 간격도 늘어난다.
또한 이런경우 관리자는 로그가 계속 증가되지 못하게 로그파일도
계속 신경을 써야한다.
고로 로그백업을 이용하면 해결된다.

로그백업은 데이터가 아닌 로그를 백업하므로 시간이 빠르다.
그리고 백업된 로그는 자동으로 삭제되기에 로그가 계속 증가하는것도
막을수 있다.

다만 로그백업도 구조변경은 먼저 풀백업이 선행되어야 한다.

Drop database test

sp_addumpdevice 'disk','testbackup20','e:\backup20.bak'
                  디바이스타입, 디바이스이름,  디바이스경로 
Create database test10

Create table aaa(aaa int)

insert into aaa values(1)

backup database test10 to testbackup20

insert into aaa values(2)

backup log test10 to testbackup20

insert into aaa values(3)

backup log test10 to testbackup20

DROP DATABASE BACKTEST

create database TEST

sp_addumpdevice 'disk','testbp','E:\backup.bak'

** 로그백업

풀백업과 디퍼런셜 백업만 하는 경우는 백업의 간격이 클수 밖에 없다.
풀백업이야 데이터베이스 전체를 백업하는 것이니 당연하고 디퍼런셜
백업도 풀백업 기준에서 멀어질수록 백업량은 커진다...
 그렇게 되면 당연히 백업 시간이 증가될것이고 자주 못할것이다.
또한 관리자는 로그가 계속 증가하지 않게 로그로 신경을 써주어야 한다.
--> 로그백업을 하면 해결( 백업된 로그는 자동으로 삭제된다 )
로그백업도 풀백업이 선행 되어야만 한다.

CREATE TABLE AAA(ID INT)

INSERT INTO AAA VALUES(1)

백업하자...

BACKUP DATABASE TEST TO TESTBP

INSERT INTO AAA VALUES(2)

BACKUP LOG TEST TO TESTBP

 백업은 DATABASE 대신에 LOG를 사용하면 된다.
 데이터베이스 옵션에서 Truncate Log on CheckPoint가 
활성화되어 있으면 하기 전에 False로 바꾼다.
 체크포인트가 발생하면 로그를 자동으로 지우기 때문에 로그백업을
못한다.

INSERT INTO AAA VALUES(3)

BACKUP LOG TEST TO TESTBP

INSERT INTO AAA VALUES(4)

BACKUP LOG TEST TO TESTBP

SELECT * FROM AAA

-데이터베이스 삭제 후 복구해 보자
USE PUBS
GO
DROP DATABASE TEST

RESTORE DATABASE TEST FROM TESTBP WITH FILE=1,
				NORECOVERY
GO
RESTORE LOG TEST FROM TESTBP WITH FILE=2,
				NORECOVERY
GO
RESTORE LOG TEST FROM TESTBP WITH FILE=3,
				NORECOVERY
GO
RESTORE LOG TEST FROM TESTBP WITH FILE=4,
				RECOVERY

SELECT * FROM TEST..AAA

로그백업 한것은 복구할 경우 로그백업한 순서대로 복원을 해야한다.
중간에 하나라도 없다면 제대로 복구할 수가 없다

USE PUBS
GO
DROP DATABASE TEST

RESTORE DATABASE TEST FROM TESTBP WITH FILE=1,NORECOVERY
GO
RESTORE LOG TEST FROM TESTBP WITH FILE=2,RECOVERY
GO
RESTORE LOG TEST FROM TESTBP WITH FILE=4,RECOVERY

SELECT * FROM TEST..AAA

만약에 백업 받은것중 실제로 3번째 것이 박살났다고 하면 두번째까지
밖에 복구가 안된다.....그 뒤의 모든 로그백업은 무용지물이 되버린다.



** 백업 및 복구 재 정리

* 복구모델 3종류

최대 모델 : 가장 많은 데이터를 복구할 수 있습니다.

                실제 문제가 발생한 시각까지의 모든 데이터를 복구가 가능

대량로그 : 마지막 로그 백업 때까지만 복구가 가능합니다.

단순 : 이 모델로 지정시 로그 백업이 불가하므로 오로지 마지막 전체 
	백업시 까지만 복구가 가능합니다.


USE master
GO

--백업을 테스트할 DB 생성
CREATE DATABASE bkupTest

sp_helpdb bkupTest

어떠세요? 흥미있게 보실 부분으로..
status라는 부분을 보시면? Recovery=FULL 이라는게 있을 겁니다.
기본 옵션으로 데이터베이스를 생성하면 복구 모델은 FULL이라는 거지요.

USE bkupTest
GO


CREATE TABLE tblBkupTest(
name varchar(10)
, age int
)
GO

INSERT INTO tblBkupTest(name, age) VALUES('홍길동', 20)
INSERT INTO tblBkupTest(name, age) VALUES('이순신', 30)
GO

--화일로 백업
BACKUP DATABASE bkupTest TO DISK='c:\bkupTest_full_bkup' 
					WITH INIT

--테이블 삭제
DROP TABLE tblBkupTest
GO

--데이터 조회 불가.
SELECT * FROM tblBkupTest

--masterDB 사용 - 해당 DB가 사용중이면 복구가 불가하기 때문
USE master
GO

--복구
restore database bkupTest from disk ='c:\bkupTest_full_bkup'
GO


USE bkupTest
GO

--데이터 조회
SELECT * FROM tblBkupTest

 
위의 케이스는 단순히 데이터베이스를 풀 백업 했습니다. 
WITH INIT은 해당 백업 타겟을  초기화 시키고 백업을 진행하라는
의미 이지요. 아울러 풀 백업을 restore 구문으로 복구 했습니다.

DROP으로 날린 테이블이 잘 복구가 되었지요?

--영구 백업 디바이스 생성
sp_addumpdevice 'disk', 'bkupTestDevice', 
				'c:\bkupTestDevice_full_bkup'

--디바이스로 백업 할때는?
BACKUP DATABASE bkupTest TO bkupTestDevice


--테이블 삭제
DROP TABLE tblBkupTest

--데이터 조회 불가.
SELECT * FROM tblBkupTest

--masterDB 사용 - 해당 DB가 사용중이면 복구가 불가하기 때문
USE master
GO
--복구
restore database bkupTest from bkupTestDevice
GO


USE bkupTest
GO
--데이터 조회
SELECT * FROM tblBkupTest


* 단순복구모델

USE pubs
GO

--pubsDB의 복구 모델을 단순으로 한다.
ALTER DATABASE pubs SET RECOVERY simple

--풀 백업 수행
BACKUP DATABASE pubs TO DISK = 'c:\pubsFull' WITH INIT

--데이터 조회
SELECT TOP 1 title_id, price FROM titles

--조회된 값은? - 꼭 적으세요.

--데이터 수정
UPDATE titles SET price = price * 2

--데이터 조회 - 조회된값 꼭 적으세요.
SELECT TOP 1 title_id, price FROM titles

--복구 모델이 단순일 경우 로그 백업이 가능한가?
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT
--불가하다.

--SQL서버 시스템 종료SHUTDOWN

--탐색기등으로 pubs의 데이터 화일인
--mdf 화일을 지우자.
--C:\Program Files\Microsoft SQL Server\MSSQL\Data
--이 기본 경로이다.

--다시 SQL서버를 시작한다.

-- EM창을 연다
--SQL서버를 시작하면 당연히 문제가 있습니다. 
--PubsDB를 로드할 수 없다고 나오지요

pubs - 주의대상 - 바로 공포의 서스펙트 모드라고 하는 혼수상태 입니다.
이렇게 데이터베이스 이름이 나오는 이유는? 데이터베이스 이름과 같은 
정보는 바로 MasterDB에 있기 때문입니다.
여하간 우리가 mdf 화일을 지웠으니 당연한가요? 
이제 복구를 해 보도록 하지요.
  

--master DB 에서 작업한다.
USE master
GO

--데이터 조회가 가능한가?
SELECT TOP 1 title_id, price FROM pubs..titles
--불가하다.

--로그 백업이 가능한가? (이후 풀모델과 비교를 위해서 입니다.)
BACKUP LOG pubs TO DISK = 'c:\pubsLogNoTrunc' WITH NO_TRUNCATE, INIT
--불가하다.

--복구를 진행하자.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'

--데이터를 조회해 보자.
SELECT TOP 1 title_id, price FROM pubs..titles

--조회된 값은?

업데이트하기 전의 값이 나온다......
오로지....가장 최근의 풀 백업본 까지만 복구가 가능하다....


* 대량로그모델

TITLE.TXT와 TITLE2.TXT 를 C:\밑에 복사한다.


--pubs DB를 대량 로그 모델로 바꾼다.
ALTER DATABASE pubs SET RECOVERY bulk_logged

--데이터베이스를 풀 백업 한다.
BACKUP DATABASE pubs to DISK = 'c:\pubsFull' WITH INIT

--데이터를 조회한다.
SELECT TOP 1 title_id, price FROM pubs..titles
--조회된 값은?

--가격을 *2 한다.
UPDATE pubs..titles SET price = price * 2

--데이터를 조회한다.
SELECT TOP 1 title_id, price FROM pubs..titles
--조회된 값은?

--BULK 작업을 한다.
--다운로드 받은 titles.txt 화일을 c:\에 둔다. 
--기본적으로 INSERT,UPDATE,DELETE작업을 로그에 기록이 남는다.
--그리고 작업한다.

BULK INSERT pubs..titles FROM 'c:\titles.txt'
--BULK INSERT 문을 사용하여 데이터 파일에 있는 데이터를 
--SQL Server 테이블로 전송할 수도 있습니다
--데이터를 조회한다.
SELECT top 2 title_id, price FROM pubs..titles

--Bulk INSERT로 삽입된 값은 BU1001 에 39.98이다.

--로그를 백업하자. - BULK INSERT가 로그에 남을까 남지 않을까?
--SQL7까지는 LOG에 남지 않는 작업이었다.
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT

--다시 하나의 데이터를 BULK INSERT로 넣자.
--지금 넣는 값은 title_id가 BU1002이며 가격은 23.9 이다.
BULK INSERT pubs..titles FROM 'c:\titles2.txt'

--데이터를 조회해 보자.
SELECT top 3 title_id, price FROM pubs..titles
--조회된 값은?

--역시나 시스템을 내리고 pubs의 mdf 화일을 지우자.
SHUTDOWN

* 복구하자

--다시 SQL서버를 시작 시키자.
USE master
GO

--데이터가 조회 가능한가? - 불가하다. 
SELECT TOP 3 title_id, price FROM pubs..titles

--데이터베이스를 복구하자.
--현재 풀백업본을 복구하는 것이다.
--이후 LOG를 복구할게 더 있으므로 옵션으로
--WITH NORECOVERY를 붙인다.

RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull' 
WITH NORECOVERY

--로그를 복구하자.
--이때 마지막 복구본 이므로
--WITH RECOVERY 옵션을 준다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLog'
WITH RECOVERY

--데이터를 조회해 보자.
SELECT TOP 3 title_id, price FROM pubs..titles


데이터를 맨 마지막에 조회해 보니 어떤가요?
대량 로그 백업 샘플에서는 분명히 마지막에 어떤 값이었지요?
BU1001, BU1002, BU1032였을 겁니다. 분명히 LOG에 BULK INSERT의 
데이터가 남았기  때문에 BU1001이 보이지요? 
또한 두번째 BULK INSERT한 BU1002값은?
추후 로그를 백업하지 않았기 때문에 볼 수 없지요.
따라서.. 대량로드 작업에서는 가장 최근의 로그 백업본 까지만!!! 
복구가 가능한 겁니다.
이제 전체 모델을 봐 보도록 하지요.

** 전체모델

--사용된 데이터베이스를 최초 상태로 복구 합니다.
--맨처음 단순모델할때 사용했던 백업본입니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'

--다음 풀모델을 위해 풀백업을 진행합니다.
BACKUP DATABASE pubs TO DISK = 'c:\pubs1' WITH INIT

--데이터를 조회해 보면?
USE PUBS
SELECT TOP 1 title_id, price FROM pubs..titles
--조회된 값은?

--price를 *2 합니다.
UPDATE pubs..titles SET price = price * 2

--BULK INSERT로 데이터를 넣습니다. 값은 BU1001입니다.
BULK INSERT pubs..titles FROM 'c:\titles.txt'

--데이터를 조회하면?
SELECT TOP 2 title_id, price FROM pubs..titles
--조회된 값은?

--로그를 백업 합니다.
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT

--또다시 BULK INSERT를 합니다.
BULK INSERT pubs..titles FROM 'c:\titles2.txt'

--데이터를 조회하면?
SELECT TOP 3 title_id, price FROM pubs..titles
--조회된 값은?

--시스템 셧다운
SHUTDOWN

--pubs의 mdf 화일을 삭제 합니다. 단!
--ldf 화일은 건드리지 마세요.

mdf 화일을 삭제 했습니다. 조회된 값은 얼마죠?

BU1001, BU1002, BU1032일 겁니다. 그렇죠?

그럼 이제 복구를 해 볼까요?

SQL 서비스를 구동 시킨다

--복구를 진행합니다.
USE master
GO

--데이터를 조회가 가능한가요? - 불가합니다.
SELECT TOP 2 title_id, price FROM pubs..titles

--로그를 백업합니다.
--바로 풀백업의 중요한 부분으로
--문제가 발생해도 로그가 깨지지 않았다면?
--로그가 백업이 됩니다.
--이때 반드시 WITH NO_TRUNCATE 옵션이 필요합니다.
--INIT는 초기화 시켜 백업하라는 옵션이지요.
BACKUP LOG pubs TO DISK = 'c:\pubsLogNoTrunc' 
			WITH NO_TRUNCATE, INIT
--로그 백업이 성공합니다.

--데이터베이스를 복구해 보도록 하지요.
--복구할게 더 있으니 NORECOVERY로 합니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
WITH NORECOVERY

--로그를 복구해 보도록 하지요.
--복구할게 더 있으니 NORECOVERY로 합니다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLog'
WITH NORECOVERY

--로그를 복구해 보도록 하지요.
--이 로그는? pubs가 깨진후 로그만 백업한것이죠?
--위에서 옵션인 WITH NO_TRUNCATE옵션으로 백업한 로그 입니다.
--복구할게 더이상 없으니 RECOVERY로 합니다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLogNoTrunc'

--데이터를 조회해 보면?
SELECT TOP 3 title_id, price FROM pubs..titles
--어디까지 복구가 되었나요?

　

** 그럼 이제 많이 받는 질문인....  개발자나 관리자의 실수로..
WHERE절 없이 DELETE나 UPDATE를 쳐 버렸을때 복구하는 방법을
알아보자

이때는 반드시 모델이 전체 모델 또는 대량 로그 이어야 합니다

--데이터베이스를 초기화 시키기 위해 리스토어 합니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'

--데이터베이스를 풀 백업 합니다.
BACKUP DATABASE pubs TO DISK = 'c:\pubs1' WITH INIT

--데이터를 조회합니다.
SELECT TOP 1 title_id, price FROM pubs..titles
--초기화가 잘 되었는지 확인하는 겁니다.

--데이터를 하나 삽입 합니다.
BULK INSERT pubs..titles FROM 'c:\titles.txt'

--데이터를 조회하면?
SELECT TOP 2 title_id, price FROM pubs..titles
--조회된 값은?

--로그를 백업해 보도록 하지요.
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT

--역시나 데이터를 하나 더 넣도록 합니다.
BULK INSERT pubs..titles FROM 'c:\titles2.txt'

--데이터를 조회하면?
SELECT TOP 3 title_id, price FROM pubs..titles
--조회된 값은?

--!!자 이제 문제 상황입니다.
--개발자의 실수로 UPDATE를 WHERE절 없이 쳐버렸습니다.
UPDATE pubs..titles SET price = 0

--컨트롤 + Z는 아무리 눌러도 데이터는 복구 안됩니다.
SELECT title_id, price FROM pubs..titles

--바로 문제가 발생한 시각을 알아야만 합니다.
SELECT GETDATE()
--결과 시각은?
--현재의 시간을 복사해서 붙이고 확인한다.
2002-05-28 01:58:12.670

--어떻게 해야 할까요?
--1. 즉시 로그를 백업 합니다.
--2. STOP AT 구문으로 복구 합니다.

--로그를 백업 합니다.
BACKUP LOG pubs TO DISK = 'c:\pubsLogNoTrunc' 
			WITH NO_TRUNCATE, INIT

--데이터베이스를 복구합니다.
--이때 첫번째 로그 백업과.. 문제가 발생한후 로그 백업 사이로
--복구를 진행해야 합니다. 그렇지요?
--STOP AT을 적절히 사용하도록 하지요.
--풀 백업본을 리스토어 합니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
WITH NORECOVERY

--첫번째 로그 백업본을 복구 합니다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLog'
WITH NORECOVERY

--문제가 발생한후 로그를 백업한 것입니다.
--약간 특이하게 STOP AT이 있습니다.
--시각 지정은.. 문제가 발생한 시각 - 1분 정도로 하겠습니다.
--2002-05-28 01:58:12.670 빼기 1분
--그래야만.. 문제가 발생하기 바로 전 시각으로 되돌릴 수 있겠지요?
--당연히 문제가 발생한후 즉시 알아야만 데이터 손실을 그만큼 줄일수 
--있겠죠
--한 일주일 정도 지난후 문제가 발생한걸 알고.. 또한
--중요한 회원 데이터였다면? 생각하기도 끔찍해 지겠지요.
RESTORE LOG pubs FROM DISK = 'c:\pubsLogNoTrunc'
WITH STOPAT = '2001-08-23 16:05:14.320', RECOVERY

--데이터를 조회해 보면?
SELECT TOP 3 title_id, price FROM pubs..titles
--원하는 데이터인 BU1001, BU1002, BU1032가 맞습니까?