Đây là dịch vụ server dùng riêng , quý khách cần có người quản trị và có chế độ tự backup và bảo vệ dữ liệu của mình trong tất cả các trường hợp bị hack hay HDD bị lỗi do nhà sản xuất HDD.
Sao lưu và khôi phục cơ sở dữ liệu trong SQL Server
(Backup and Restore Database in SQL Server)
Sao lưu và khôi phục dữ liệu là vấn đề rất quan trọng khi quản trị CSDL, đảm bảo cho dữ liệu không bị mất mát và nếu có sự cố xảy ra thì có thể khôi phục lại trạng thái của CSDL trước khi xảy ra sự cố. Công việc này phải dựa vào cơ chế Backup và Restore của các hệ QTCSDL, và để thực hiện tốt công việc này thì người quản trị dữ liệu phải có kịch bản sao lưu và khôi phục CSDL cho hệ thống một cách cẩn thận và chi tiết.
SQL Server cung cấp ba loại backup như sau:
Full Backup: Backup toàn bộ dữ liệu tại thời điểm thực hiện (thường dùng nhất).
Differential Backup: Backup các dữ liệu mới được cập nhật kể từ lần full backup trước đó.
Transaction Log Backup: Backup các log record hiện có trong log file. Nghĩa là sao lưu các hành động (các thao tác xảy ra đối với database) chứ không sao lưu dữ liệu. Đồng thời nó cũng cắt bỏ (truncate) log file, loại bỏ các log record vừa được backup ra khỏi log file. Vì thế khi thấy log file tăng quá lớn, có nhiều khả năng là bạn chưa từng backup transaction log bao giờ.
Một nguyên tắc chung để giảm thiểu mất mát dữ liệu khi có sự cố là tăng tần suất backup. Tuy nhiên với một database có dung lượng lớn và được cập nhật liên tục, thì việc thực hiện full backup với tần suất cao là không khả thi, vì nó dùng rất nhiều tài nguyên (CPU, I/O). Nhờ có differential backup và transaction log backup, bạn có thể tạo lập các phương án sao lưu thích hợp, đảm bảo dữ liệu được backup thường xuyên hơn mà không chiếm nhiều tài nguyên của hệ thống.
Chẳng hạn, một kịch bản sao lưu và khôi phục dữ liệu tham khảo như sau:
Full backup: Một lần mỗi ngày vào 2h sáng.
Differential backup: vào các thời điểm 6h, 10h, 14h, 18h, 22h (5 lần/ngày).
Transaction log backup: 15 phút một lần vào các thời điểm 5′, 20′, 35′, và 50′ của mỗi giờ (4 lần/giờ).
Lưu ý Differential backup luôn sao lưu các dữ liệu đã thay đổi kể từ lần full backup trước (trong ví dụ trên là các dữ liệu đã thay đổi kể từ 2h), chứ không phải từ lần differential backup trước đó. Vì thế bản backup lúc 10h sẽ bao gồm các dữ liệu đã được sao lưu trong bản backup lúc 6h, bản backup lúc 14h gồm các dữ liệu đã có trong bản 10h…
Transaction log backup chỉ sao lưu các log record kể từ lần transaction log backup trước đó.
Giả sử Database bị hỏng vào thời điểm 10h55′, bạn cần khôi phục lại database theo trình tự sau:
Bước 1. Khôi phục từ bản full backup gần với thời điểm có sự cố nhất (bản full backup lúc 2h).
Bước 2. Khôi phục từ bản differential backup gần với thời điểm có sự cố nhất (bản lúc 10h).
Bước 3. Khôi phục tất cả các transaction log backup kể từ sau lần diferential backup gần nhất, lần lượt theo trình tự thời gian. Đó là các bản tại các thời điểm 10h5′, 10h20′, 10h35′, và 10h50′.
Bước 1 và 2 đưa database trở lại trạng thái giống như lúc 10h. Ở bước 3, với mỗi lần khôi phục transaction log thì các thao tác chứa trong đó được đem ra thực hiện lại trên database (gọi là log forwarding) và do đó đưa nó về trạng thái gần hơn thời điểm xảy ra sự cố. Như vậy sau khi hoàn tất khôi phục bốn bản transaction log backup thì database sẽ ở vào trạng thái giống như lúc 10h50′. Tuy nhiên các thay đổi diễn ra trong 5 phút sau đó (từ 10h50′ đến 10h55′) đã bị mất.
Trong trường hợp may mắn hơn, khi sự cố xảy ra mà log file vẫn còn nguyên vẹn, bạn sẽ có cơ hội đưa database trở lại trạng thái ngay trước khi có sự cố, và do đó không có mất mát dữ liệu. Việc đầu tiên bạn cần làm là thực hiện ngay transaction log backup (nên nhớ, không được vội vàng khôi phục từ bản full backup). Sau đó các bước tiếp theo sẽ tương tự như trên:
Bước 0. Sao lưu transaction log.
Bước 1. Khôi phục từ full backup file lúc 2h sáng hôm đó.
Bước 2. Khôi phục từ differential backup file lúc 10h.
Bước 3. Khôi phục các transaction log backup file kể từ sau 10h, lần lượt theo trình tự thời gian: các bản backup vào lúc 10h5′, 10h20′, 10h35′, 10h50′, và cuối cùng bản lúc 10h55′ (vừa thực hiện ở bước 0).
Facebook
