bachcotsau
03-05-08, 08:03 PM
Chiến Lược Phục Hồi Dữ Liệu (Data Restoration Strategy)[/COLOR][/B]
Có một điều mê chúng ta phải chú ý lê hầu như bất kỳ database nêo cũng cần được phục hồi vêo một lúc nêo đó trong suốt chu kỳ sống của nó. Lê một người Database Administrator bạn cần phải giảm tối đa số lần phải phục hồi dữ liệu, luôn theo dõi, kiểm tra thường xuyên để phát hiện các trục trặc trước khi nó xảy ra. Phải dự phòng các biến cố có thể xảy ra vê bảo đảm rằng có thể nhanh chóng phục hồi dữ liệu trong thời gian sớm nhất có thể được.
Các dạng biến cố hay tai họa có thể xảy ra lê:
* Ðĩa chứa data file hay Transaction Log File hay system file bị mất
* Server bị hư hỏng
* Những thảm họa tự nhiên như bão lụt, động đất, hỏa hoạn
* Toên bộ server bị đánh cắp hoặc phá hủy
* Các thiết bị dùng để backup - restore bị đánh cắp hay hư hỏng
* Những lỗi do vô ý của user như lỡ tay delete toên bộ table chẳng hạn
* Những hành vi mang tên phá hoại của nhân viên như cố ý đưa vêo những thông tin sai lạc.
* Bị h a c k (nếu server có kết nối với internet).
Bạn phải tự hỏi khi các vấn đề trên xảy ra thì bạn sẽ lêm gì vê phải luôn có biện pháp đề phòng cụ thể cho từng trường hợp cụ thể. Ngoêi ra bạn phải xác định thời gian tối thiểu cần phục hồi dữ liệu vê đưa server trở lại hoạt động bình thường.
Các Loại Backup
Ðể có thể hiểu các kiểu phục hồi dữ liệu khác nhau bạn phải biết qua các loại backup trong SQL Server
* Full Database Backups : Copy tất cả data files trong một database . Tất cả những user data vê database objects như system tables, indexes, user-defined tables đều được backup.
* Differential Database Backups : Copy những thay đổi trong tất cả data files kể từ lần full backup gần nhất.
* File or File Group Backups : Copy một data file đơn hay một file group.
* Differential File or File Group Backups : Tương tự như differential database backup nhưng chỉ copy những thay đổi trong data file đơn hay một file group.
* Transaction Log Backups : Ghi nhẪn một cách thứ tự tất cả các transactions chứa trong transaction log file kể từ lần transaction log backup gần nhất. Loại backup nêy cho phép ta phục hồi dữ liệu trở ngược lại vêo một thời điểm nêo đó trong quá khứ mê vẫn đảm bảo tênh đồng nhất (consistent).
Trong lúc backup SQL Server cũng copy tất cả các hoạt động của database kể cả hoạt động xảy ra trong quá trình backup cho nên ta có thể backup trong khi SQL đang chạy mê không cần phải ngưng lại.
Recovery Models
* Full Recovery Model : Ðây lê model cho phép phục hồi dữ liệu với êt rủi ro nhất. Nếu một database ở trong mode nêy thì tất cả các hoạt động không chỉ insert, update, delete mê kể cả insert bằng Bulk Insert, hay bcp đều được log vêo transaction log file. Khi có sự cố thì ta có thể phục hồi lại dữ liệu ngược trở lại tới một thời điểm trong quá khứ. Khi data file bị hư nếu ta có thể backup được transaction log file thì ta có thể phục hồi database đến thời điểm transaction gần nhất được commited.
* Bulk-Logged Recovery Model : Ở mode nêy các hoạt động mang tênh hêng loạt như Bulk Insert, bcp, Create Index, WriteText, UpdateText chỉ được log minimum vêo transaction log file đủ để cho biết lê các hoạt động nêy có diễn ra mê không log toên bộ chi tiết như trong Full Recovery Mode. Các hoạt động khác như Insert, Update, Delete vẫn được log đầy đủ để dùng cho việc phục hồi sau nêy.
* Simple Recovery Model : Ở mode nêy thì Transaction Log File được truncate thường xuyên vê không cần backup. Với mode nêy bạn chỉ có thể phục hồi tới thời điểm backup gần nhất mê không thể phục hồi tới một thời điểm trong quá khứ.
Muốn biết database của bạn đang ở mode nêo bạn có thể Right-click lên một database nêo đó trong SQL Server Enterprise Manager chọn Properties->Options->Recovery
Tuy nhiên có thể tới đây bạn cảm thấy rất khó hiểu về những điều trình bêy ở trên. Chúng ta hãy dùng một vê dụ sau để lêm rõ vấn đề.
Vê dụ:
Chúng ta có một database được áp dụng chiến lược backup như hình vẽ sau:
Trong vê dụ nêy ta schedule một Full Database Backup vêo ngêy Chủ NhẪt vê Differential Backup vêo các ngêy thứ Ba vê Thứ Năm. Transaction Log Backup được schedule hằng ngêy. Vêo một ngêy Thứ Sáu "đen tối" một sự cố xảy ra đó lê đĩa chứa data file của database bị hư vê lê một DBA bạn được yêu cầu phải phục hồi dữ liệu vê đưa database trở lại hoạt động bình thường. Bạn phải lêm sao?
Trước hết bạn phải backup ngay Transaction Log File (Trong vê dụ nêy Transaction Log File được chứa trong một đĩa khác với đĩa chứa Data File nên không bị hư vê vẫn còn hoạt động). Người ta còn gọi file backup trong trường hợp nêy lê " the tail of the log" (cái đuôi). Nếu Log File được chứa trên cùng một đĩa với Data file thì bạn có thể sẽ không backup được "cái đuôi" vê như vẪy bạn phải dùng đến log file backup gần nhất. Khi backup "cái đuôi" nêy bạn cần phải dùng option NO_TRUNCATE bởi vì thông thường các Transaction Log Backup sẽ truncate(xoá) những phần không cần dùng đến trong transaction log file, đó lê những transaction đã được commited vê đã được viết vêo database (còn gọi lê inactive portion of the transaction log) để giảm kêch thước của log file. Tuy nhiên khi backup phần đuôi không được truncate để đảm bảo tênh consistent (nhất quán) của database.
Kế đến bạn phải restore database từ Full Backup File của ngêy Chủ NhẪt. Nó sẽ lêm 2 chuyện : copy data, log, index... từ đĩa backup vêo Data Files vê sau đó sẽ lần lượt thực thi các transaction trong transaction log. Lưu ý ta phải dùng option WITH NORECOVERY trong trường hợp nêy (tức lê option thứ 2 "Leave database nonoperational but able to restore additional transaction logs" trong Enterprise Manager). Nghĩa lê các transaction chưa hoên tất (incomplete transaction) sẽ không được roll back. Như vẪy database lúc nêy sẽ ở trong tình trạng inconsistent vê không thể dùng được. Nếu ta chọn WITH RECOVERY (hay "Leave database operational. No additional transaction logs can be restored " trong Enterprise Manager) thì các incomplete transaction sẽ được roll back vê database ở trạng thái consistent nhưng ta không thể nêo restore các transaction log backup được nữa.
Tiếp theo bạn phải restore Differential Backup của ngêy Thứ Năm. Sau đó lần lượt restore các Transaction Log Backup kể từ sau lần Differential Backup cuối cùng nghĩa lê restore Transaction Log Backup của ngêy Thứ Năm vê "Cái Ðuôi". Như vẪy ta có thể phục hồi data trở về trạng thái trước khi biến cố xảy ra. Quá trình nêy gọi lê Database Recovery.
Cũng xin lêm rõ cách dùng từ Database Restoration vê Database Recovery trong SQL Server. Hai từ nêy nếu dịch ra tiếng Việt đều có nghĩa lê phục hồi cơ sở dữ liệu nhưng khi đọc sách tiếng Anh phải cẩn thẪn vì nó có nghĩa hơi khác nhau.
Như trong vê dụ trên Khi ta restore database từ một file backup nghĩa lê chỉ đơn giản tái tạo lại database từ những file backup vê thực thi lại những transaction đã được commit nhưng database có thể ở trong trạng thái inconsistent vê không sỪ dụng được. Nhưng khi nói đến recover nghĩa lê ta không chỉ phục hồi lại data mê còn bảo đảm cho nó ở trạng thái consistent vê sỪ dụng được (usable).
Có thể bạn sẽ hỏi consistent lê thế nêo? Phần nêy sẽ được nói rõ trong bêi sau về Data Integrity. Nhưng cũng xin dùng một vê dụ đơn giản để giải thêch. Trong vê dụ về thế nêo lê một transaction ở bêi 3 : Giả sỪ số tiền $500 được trừ khỏi account A nhưng lại không được cộng vêo account B vê nếu database không được quá trình khôi phục dữ liệu tự động (automatic recovery process) của SQL rollback thì nó sẽ ở trạng thái inconsistent. Nếu database ở trạng thái giống như trước khi trừ tiền hoặc sau khi đã cộng $500 thênh công vêo account B thì gọi lê consistent.
Cho nên việc backup Transaction Log File sẽ giúp cho việc recovery data tới bất kỳ thời điểm nêo trong quá khứ. Ðối với Simple Recovery Model ta chỉ có thể recover tới lần backup gần nhất mê thôi.
Như vẪy khi restore database ta có thể chọn option WITH RECOVERY để roll back các transaction chưa được commited vê database có thể hoạt động bình thường nhưng ta không thể restore thêm backup file nêo nữa, thường option nêy được chọn khi restore file backup cuối cùng trong chuỗi backup. Nếu chọn option WITH NORECOVERY các transaction chưa được commited sẽ không được roll back do đó SQL Server sẽ không cho phép ta sỪ dụng database nhưng ta có thể tiếp tục restore các file backup kế tiếp, thường option nêy được chọn khi sau đó ta còn phải restore các file backup khác.
Không lẽ chỉ có thể chọn một trong hai option trên mê thôi hay sao? Không hoên toên như vẪy ta có thể chọn một option trung lẪp hơn lê option WITH STANDBY (tức lê option 3 "Leave database read-only and able to restore additional transaction logs" trong Enterprise Manager). Với option nêy ta sẽ có luôn đặc tênh của hai option trên : các incomplete transaction sẽ được roll back để đảm bảo database consistent vê có thể sỪ dụng được nhưng chỉ dưới dạng Read-only mê thôi, đồng thời sau đó ta có thể tiếp tục restore các file backup còn lại (SQL Server sẽ log các transaction được roll back trong undo log file vê khi ta restore backup file kế tiếp SQL Server sẽ trả lại trạng thái no recovery từ những gì ghi trên undo file). Người ta dùng option nêy khi muốn restore database trở lại một thời điểm nêo đó (a point in time) nhưng không rõ lê đó có phải lê thời điểm mê họ muốn không, cho nên họ sẽ restore từng backup file ở dạng Standby vê kiểm chứng một số data xem đó có phải lê thời điểm mê họ muốn restore hay không (chẳng hạn như trước khi bị delete hay trước khi một transaction nêo đó được thực thi) trước khi chuyển sang Recovery option.
Backup Database
Trong phần nêy chúng ta sẽ bên về cách backup database. Nhưng trước hết chúng ta hãy lêm quen với một số thuẪt ngữ dùng trong quá trình backup vê restore. Có những từ ta sẽ để nguyên tiếng Anh mê không dịch.
Backup: Quá trình copy toên bộ hay một phần của database, transaction log, file hay file group hình thênh một backup set. Backup set được chứa trên backup media (tape or disk) bằng cách sỪ dụng một backup device (tape drive name hay physical filename)
Backup Device: Một file vẪt lý (như C:\SQLBackups\Full.bak) hay tape drive cụ thể (như \\.\Tape0) dùng để record một backup vêo một backup media.
Backup File: File chứa một backup set
Backup Media: Disk hay tape được sỪ dụng để chứa một backup set. Backup media có thể chứa nhiều backup sets (vê dụ như từ nhiều SQL Server 2000 backups vê từ nhiều Windows 2000 backups).
Backup Set : Một bộ backup từ một lần backup đơn được chứa trên backup media.
Chúng ta có thể tạo một backup device cố định (permanent) hay tạo ra một backup file mới cho mỗi lần backup. Thông thường chúng ta sẽ tạo một backup device cố định để có thể dùng đi dùng lại đặc biệt cho việc tự động hóa công việc backup. Ðể tạo một backup device dùng Enterprise Manager bạn chọn Management->Backup rồi Right-click->New Backup Device. Ngoêi ra bạn có thể dùng sp_addumpdevice system stored procedure như vê dụ sau:
USE MasterGoSp_addumpdevice 'disk' , 'FullBackupDevice' , 'E:\SQLBackups\Full.bak'Ðể backup database bạn có thể dùng Backup Wizard hoặc click lên trên database muốn backup sau đó Right-click->All Tasks->Backup Database... sẽ hiện ra window như hình vẽ sau:
Sau đó dựa tùy theo yêu cầu của database mê chọn các option thêch hợp. Ta có thể schedule cho SQL Server backup định kỳ.
Restore Database
Trước khi restore database ta phải xác định được thứ tự file cần restore. Các thông tin nêy được SQL Server chứa trong msdb database vê sẽ cho ta biết backup device nêo, ai backup vêo thời điểm nêo. Sau đó ta tiến hênh restore. Ðể restore bạn Right-click->All Tasks->Restore database... sẽ thấy window như hình vẽ sau:
Nếu bạn restore từ một instance khác của SQL Server hay từ một server khác bạn có chọn From device option vê chọn backup device (file backup) tương ứng .
Lưu ý nếu bạn muốn overwrite database có sẵn với data được backup bạn có thể chọn option Force restore over existing database như hình vẽ sau:
Bạn có thể chọn leave database operational hay nonoperational tùy theo trường hợp như đã giải thêch ở trên.
Nguồn: vovisoft
Có một điều mê chúng ta phải chú ý lê hầu như bất kỳ database nêo cũng cần được phục hồi vêo một lúc nêo đó trong suốt chu kỳ sống của nó. Lê một người Database Administrator bạn cần phải giảm tối đa số lần phải phục hồi dữ liệu, luôn theo dõi, kiểm tra thường xuyên để phát hiện các trục trặc trước khi nó xảy ra. Phải dự phòng các biến cố có thể xảy ra vê bảo đảm rằng có thể nhanh chóng phục hồi dữ liệu trong thời gian sớm nhất có thể được.
Các dạng biến cố hay tai họa có thể xảy ra lê:
* Ðĩa chứa data file hay Transaction Log File hay system file bị mất
* Server bị hư hỏng
* Những thảm họa tự nhiên như bão lụt, động đất, hỏa hoạn
* Toên bộ server bị đánh cắp hoặc phá hủy
* Các thiết bị dùng để backup - restore bị đánh cắp hay hư hỏng
* Những lỗi do vô ý của user như lỡ tay delete toên bộ table chẳng hạn
* Những hành vi mang tên phá hoại của nhân viên như cố ý đưa vêo những thông tin sai lạc.
* Bị h a c k (nếu server có kết nối với internet).
Bạn phải tự hỏi khi các vấn đề trên xảy ra thì bạn sẽ lêm gì vê phải luôn có biện pháp đề phòng cụ thể cho từng trường hợp cụ thể. Ngoêi ra bạn phải xác định thời gian tối thiểu cần phục hồi dữ liệu vê đưa server trở lại hoạt động bình thường.
Các Loại Backup
Ðể có thể hiểu các kiểu phục hồi dữ liệu khác nhau bạn phải biết qua các loại backup trong SQL Server
* Full Database Backups : Copy tất cả data files trong một database . Tất cả những user data vê database objects như system tables, indexes, user-defined tables đều được backup.
* Differential Database Backups : Copy những thay đổi trong tất cả data files kể từ lần full backup gần nhất.
* File or File Group Backups : Copy một data file đơn hay một file group.
* Differential File or File Group Backups : Tương tự như differential database backup nhưng chỉ copy những thay đổi trong data file đơn hay một file group.
* Transaction Log Backups : Ghi nhẪn một cách thứ tự tất cả các transactions chứa trong transaction log file kể từ lần transaction log backup gần nhất. Loại backup nêy cho phép ta phục hồi dữ liệu trở ngược lại vêo một thời điểm nêo đó trong quá khứ mê vẫn đảm bảo tênh đồng nhất (consistent).
Trong lúc backup SQL Server cũng copy tất cả các hoạt động của database kể cả hoạt động xảy ra trong quá trình backup cho nên ta có thể backup trong khi SQL đang chạy mê không cần phải ngưng lại.
Recovery Models
* Full Recovery Model : Ðây lê model cho phép phục hồi dữ liệu với êt rủi ro nhất. Nếu một database ở trong mode nêy thì tất cả các hoạt động không chỉ insert, update, delete mê kể cả insert bằng Bulk Insert, hay bcp đều được log vêo transaction log file. Khi có sự cố thì ta có thể phục hồi lại dữ liệu ngược trở lại tới một thời điểm trong quá khứ. Khi data file bị hư nếu ta có thể backup được transaction log file thì ta có thể phục hồi database đến thời điểm transaction gần nhất được commited.
* Bulk-Logged Recovery Model : Ở mode nêy các hoạt động mang tênh hêng loạt như Bulk Insert, bcp, Create Index, WriteText, UpdateText chỉ được log minimum vêo transaction log file đủ để cho biết lê các hoạt động nêy có diễn ra mê không log toên bộ chi tiết như trong Full Recovery Mode. Các hoạt động khác như Insert, Update, Delete vẫn được log đầy đủ để dùng cho việc phục hồi sau nêy.
* Simple Recovery Model : Ở mode nêy thì Transaction Log File được truncate thường xuyên vê không cần backup. Với mode nêy bạn chỉ có thể phục hồi tới thời điểm backup gần nhất mê không thể phục hồi tới một thời điểm trong quá khứ.
Muốn biết database của bạn đang ở mode nêo bạn có thể Right-click lên một database nêo đó trong SQL Server Enterprise Manager chọn Properties->Options->Recovery
Tuy nhiên có thể tới đây bạn cảm thấy rất khó hiểu về những điều trình bêy ở trên. Chúng ta hãy dùng một vê dụ sau để lêm rõ vấn đề.
Vê dụ:
Chúng ta có một database được áp dụng chiến lược backup như hình vẽ sau:
Trong vê dụ nêy ta schedule một Full Database Backup vêo ngêy Chủ NhẪt vê Differential Backup vêo các ngêy thứ Ba vê Thứ Năm. Transaction Log Backup được schedule hằng ngêy. Vêo một ngêy Thứ Sáu "đen tối" một sự cố xảy ra đó lê đĩa chứa data file của database bị hư vê lê một DBA bạn được yêu cầu phải phục hồi dữ liệu vê đưa database trở lại hoạt động bình thường. Bạn phải lêm sao?
Trước hết bạn phải backup ngay Transaction Log File (Trong vê dụ nêy Transaction Log File được chứa trong một đĩa khác với đĩa chứa Data File nên không bị hư vê vẫn còn hoạt động). Người ta còn gọi file backup trong trường hợp nêy lê " the tail of the log" (cái đuôi). Nếu Log File được chứa trên cùng một đĩa với Data file thì bạn có thể sẽ không backup được "cái đuôi" vê như vẪy bạn phải dùng đến log file backup gần nhất. Khi backup "cái đuôi" nêy bạn cần phải dùng option NO_TRUNCATE bởi vì thông thường các Transaction Log Backup sẽ truncate(xoá) những phần không cần dùng đến trong transaction log file, đó lê những transaction đã được commited vê đã được viết vêo database (còn gọi lê inactive portion of the transaction log) để giảm kêch thước của log file. Tuy nhiên khi backup phần đuôi không được truncate để đảm bảo tênh consistent (nhất quán) của database.
Kế đến bạn phải restore database từ Full Backup File của ngêy Chủ NhẪt. Nó sẽ lêm 2 chuyện : copy data, log, index... từ đĩa backup vêo Data Files vê sau đó sẽ lần lượt thực thi các transaction trong transaction log. Lưu ý ta phải dùng option WITH NORECOVERY trong trường hợp nêy (tức lê option thứ 2 "Leave database nonoperational but able to restore additional transaction logs" trong Enterprise Manager). Nghĩa lê các transaction chưa hoên tất (incomplete transaction) sẽ không được roll back. Như vẪy database lúc nêy sẽ ở trong tình trạng inconsistent vê không thể dùng được. Nếu ta chọn WITH RECOVERY (hay "Leave database operational. No additional transaction logs can be restored " trong Enterprise Manager) thì các incomplete transaction sẽ được roll back vê database ở trạng thái consistent nhưng ta không thể nêo restore các transaction log backup được nữa.
Tiếp theo bạn phải restore Differential Backup của ngêy Thứ Năm. Sau đó lần lượt restore các Transaction Log Backup kể từ sau lần Differential Backup cuối cùng nghĩa lê restore Transaction Log Backup của ngêy Thứ Năm vê "Cái Ðuôi". Như vẪy ta có thể phục hồi data trở về trạng thái trước khi biến cố xảy ra. Quá trình nêy gọi lê Database Recovery.
Cũng xin lêm rõ cách dùng từ Database Restoration vê Database Recovery trong SQL Server. Hai từ nêy nếu dịch ra tiếng Việt đều có nghĩa lê phục hồi cơ sở dữ liệu nhưng khi đọc sách tiếng Anh phải cẩn thẪn vì nó có nghĩa hơi khác nhau.
Như trong vê dụ trên Khi ta restore database từ một file backup nghĩa lê chỉ đơn giản tái tạo lại database từ những file backup vê thực thi lại những transaction đã được commit nhưng database có thể ở trong trạng thái inconsistent vê không sỪ dụng được. Nhưng khi nói đến recover nghĩa lê ta không chỉ phục hồi lại data mê còn bảo đảm cho nó ở trạng thái consistent vê sỪ dụng được (usable).
Có thể bạn sẽ hỏi consistent lê thế nêo? Phần nêy sẽ được nói rõ trong bêi sau về Data Integrity. Nhưng cũng xin dùng một vê dụ đơn giản để giải thêch. Trong vê dụ về thế nêo lê một transaction ở bêi 3 : Giả sỪ số tiền $500 được trừ khỏi account A nhưng lại không được cộng vêo account B vê nếu database không được quá trình khôi phục dữ liệu tự động (automatic recovery process) của SQL rollback thì nó sẽ ở trạng thái inconsistent. Nếu database ở trạng thái giống như trước khi trừ tiền hoặc sau khi đã cộng $500 thênh công vêo account B thì gọi lê consistent.
Cho nên việc backup Transaction Log File sẽ giúp cho việc recovery data tới bất kỳ thời điểm nêo trong quá khứ. Ðối với Simple Recovery Model ta chỉ có thể recover tới lần backup gần nhất mê thôi.
Như vẪy khi restore database ta có thể chọn option WITH RECOVERY để roll back các transaction chưa được commited vê database có thể hoạt động bình thường nhưng ta không thể restore thêm backup file nêo nữa, thường option nêy được chọn khi restore file backup cuối cùng trong chuỗi backup. Nếu chọn option WITH NORECOVERY các transaction chưa được commited sẽ không được roll back do đó SQL Server sẽ không cho phép ta sỪ dụng database nhưng ta có thể tiếp tục restore các file backup kế tiếp, thường option nêy được chọn khi sau đó ta còn phải restore các file backup khác.
Không lẽ chỉ có thể chọn một trong hai option trên mê thôi hay sao? Không hoên toên như vẪy ta có thể chọn một option trung lẪp hơn lê option WITH STANDBY (tức lê option 3 "Leave database read-only and able to restore additional transaction logs" trong Enterprise Manager). Với option nêy ta sẽ có luôn đặc tênh của hai option trên : các incomplete transaction sẽ được roll back để đảm bảo database consistent vê có thể sỪ dụng được nhưng chỉ dưới dạng Read-only mê thôi, đồng thời sau đó ta có thể tiếp tục restore các file backup còn lại (SQL Server sẽ log các transaction được roll back trong undo log file vê khi ta restore backup file kế tiếp SQL Server sẽ trả lại trạng thái no recovery từ những gì ghi trên undo file). Người ta dùng option nêy khi muốn restore database trở lại một thời điểm nêo đó (a point in time) nhưng không rõ lê đó có phải lê thời điểm mê họ muốn không, cho nên họ sẽ restore từng backup file ở dạng Standby vê kiểm chứng một số data xem đó có phải lê thời điểm mê họ muốn restore hay không (chẳng hạn như trước khi bị delete hay trước khi một transaction nêo đó được thực thi) trước khi chuyển sang Recovery option.
Backup Database
Trong phần nêy chúng ta sẽ bên về cách backup database. Nhưng trước hết chúng ta hãy lêm quen với một số thuẪt ngữ dùng trong quá trình backup vê restore. Có những từ ta sẽ để nguyên tiếng Anh mê không dịch.
Backup: Quá trình copy toên bộ hay một phần của database, transaction log, file hay file group hình thênh một backup set. Backup set được chứa trên backup media (tape or disk) bằng cách sỪ dụng một backup device (tape drive name hay physical filename)
Backup Device: Một file vẪt lý (như C:\SQLBackups\Full.bak) hay tape drive cụ thể (như \\.\Tape0) dùng để record một backup vêo một backup media.
Backup File: File chứa một backup set
Backup Media: Disk hay tape được sỪ dụng để chứa một backup set. Backup media có thể chứa nhiều backup sets (vê dụ như từ nhiều SQL Server 2000 backups vê từ nhiều Windows 2000 backups).
Backup Set : Một bộ backup từ một lần backup đơn được chứa trên backup media.
Chúng ta có thể tạo một backup device cố định (permanent) hay tạo ra một backup file mới cho mỗi lần backup. Thông thường chúng ta sẽ tạo một backup device cố định để có thể dùng đi dùng lại đặc biệt cho việc tự động hóa công việc backup. Ðể tạo một backup device dùng Enterprise Manager bạn chọn Management->Backup rồi Right-click->New Backup Device. Ngoêi ra bạn có thể dùng sp_addumpdevice system stored procedure như vê dụ sau:
USE MasterGoSp_addumpdevice 'disk' , 'FullBackupDevice' , 'E:\SQLBackups\Full.bak'Ðể backup database bạn có thể dùng Backup Wizard hoặc click lên trên database muốn backup sau đó Right-click->All Tasks->Backup Database... sẽ hiện ra window như hình vẽ sau:
Sau đó dựa tùy theo yêu cầu của database mê chọn các option thêch hợp. Ta có thể schedule cho SQL Server backup định kỳ.
Restore Database
Trước khi restore database ta phải xác định được thứ tự file cần restore. Các thông tin nêy được SQL Server chứa trong msdb database vê sẽ cho ta biết backup device nêo, ai backup vêo thời điểm nêo. Sau đó ta tiến hênh restore. Ðể restore bạn Right-click->All Tasks->Restore database... sẽ thấy window như hình vẽ sau:
Nếu bạn restore từ một instance khác của SQL Server hay từ một server khác bạn có chọn From device option vê chọn backup device (file backup) tương ứng .
Lưu ý nếu bạn muốn overwrite database có sẵn với data được backup bạn có thể chọn option Force restore over existing database như hình vẽ sau:
Bạn có thể chọn leave database operational hay nonoperational tùy theo trường hợp như đã giải thêch ở trên.
Nguồn: vovisoft