Khái niệm backup (sao lưu) và restore (khôi phục) chắc hẳn đã quen
thuộc đối với đa số chúng ta: bạn thường xuyên backup, ví dụ copy toàn
bộ thư mục sang một thiết bị lưu trữ khác, để phòng khi gặp sự cố gây
mất mát dữ liệu thì có thể copy ngược trở lại. Với database thì việc
backup diễn ra có khác, khi hệ thống đang vận hành thì bạn không thể đơn
giản copy các data file và log file vì chúng bị khóa hoàn toàn. Bạn
phải dựa vào cơ chế backup của hệ QTCSDL.
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 đó. Đây có lẽ là loại được dùng thường xuyên nhất.
· Differential backup: backup các trang 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à nó 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ờ.
· Differential backup: backup các trang 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à nó 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 bớt lượng dữ liệu mất mát 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 CPU và 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. Ví dụ, bạn có thể thực hiện:
· 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ờ). Chọn thời điểm như vậy để đảm bảo
nó xảy ra sau differential backup.
Lưu ý là differential backup luôn sao lưu các trang đã thay đổi kể từ
lần full backup trước (trong ví dụ trên là các trang đã 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 trang lưu trong bản lúc 6h, bản 14h gồm
các trang đã có trong bản 10h… Transaction log backup thì ngược lại, 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 đây 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′, 1oh20′, 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′) đã vĩnh viễn 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 của sáng sớm 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′,
1oh20′, 10h35′, 10h50′, và cuối cùng bản lúc 10h55′ (vừa thực hiện ở
bước 0).
Trong bài sau tôi sẽ giới thiệu script thực hiện từng bước qua một ví dụ cụ thể.
0 comments:
Post a Comment