12 Sai lầm Phổ Biến khi Sao Lưu Cơ Sở Dữ Liệu

bởi Alexey Kovyazin, 11-Tháng Mười Một-2015

Tải PDF (Tiếng Anh) Bài viết này ban đầu được viết cho các nhà phát triển và quản trị viên DBMS Firebird, nhưng việc tiếp xúc với các quản trị viên của các cơ sở dữ liệu khác cho thấy rõ rằng hầu hết các sai lầm đều phổ biến ở họ và gần như ai cũng vấp phải những hòn đá gần như giống nhau. Nếu bạn có thể bổ sung điều gì đó vào danh sách này (thậm chí là điều gì đó cụ thể cho một DBMS cụ thể), hãy liên hệ với chúng tôi qua e-mail [email protected].

1. Xóa bản sao lưu trước đó trước khi tạo bản sao lưu mới

Sai lầm này phổ biến nhất ở những người mới bắt đầu, những người không nhận ra rằng mục đích chính của bản sao lưu cơ sở dữ liệu không chỉ là tạo một bản sao cơ sở dữ liệu, mà là làm cho thời gian gián đoạn của hệ thống thông tin (một phần quan trọng trong đó là cơ sở dữ liệu) ngắn nhất có thể.

Kết quả là, hệ thống không được bảo vệ từ thời điểm bản sao lưu mới nhất bị xóa cho đến thời điểm bản sao lưu mới được tạo vì cơ sở dữ liệu không có một bản sao lưu nào trong giai đoạn này. Vì việc tạo bản sao lưu có thể mất khá nhiều thời gian, đây là thời điểm hoàn hảo để định luật Murphy phát huy tác dụng. Cách tiếp cận này đặc biệt hiệu quả khi kết hợp với Vấn đề 7 (xem bên dưới).

Khuyến nghị: đừng xóa bản sao lưu trước đó trước khi tạo bản sao lưu mới! (và đừng tạo bản sao lưu mới vào một tệp đã tồn tại).

Khuyến nghị cho Firebird: Có một công cụ FBDataGuard được bao gồm trong HQbird(một gói phân phối nâng cao của Firebird) chỉ xóa bản sao lưu cũ nhất trong lịch sử sau khi một bản sao lưu mới được tạo.

2. Ghi đè lên cơ sở dữ liệu hiện có khi khôi phục từ bản sao lưu

Sai lầm này ít phổ biến hơn mặc dù hậu quả có thể tồi tệ hơn nhiều. Nếu bản sao lưu chưa được xác minh và hóa ra bị hỏng (xem Vấn đề 6), bạn sẽ không có cả bản sao cơ sở dữ liệu trước đó lẫn bản sao lưu hợp lệ.

Tình trạng lộn xộn như thế này thường xảy ra vào tối thứ Sáu khi mọi thứ trở nên hỗn loạn và khi chỉ đạo từ ban quản lý trở nên khá mâu thuẫn. Một chút xui xẻo và một ngày cuối tuần uể oải trong phòng máy chủ là điều dành cho bạn.

Firebird có một loại bảo vệ chống lại sai lầm này - sẽ không thể khôi phục cơ sở dữ liệu từ bản sao lưu bằng tiện ích gbak nếu công tắc -create mặc định của nó được bật và nếu tên tệp được chỉ định trỏ đến một cơ sở dữ liệu hiện có. Thật không may, có một cách để vượt qua sự bảo vệ này: công tắc -rep vẫn cho phép bạn ghi đè lên tệp hiện có.

Khuyến nghị: không bao giờ ghi đè lên tệp của cơ sở dữ liệu đang hoạt động mà không có chỉ đạo bằng văn bản từ ban quản lý của bạn.

Khuyến nghị cho Firebird: Sử dụng FBDataGuard vì nó không bao giờ ghi đè lên tệp cơ sở dữ liệu.

3. Sử dụng sao lưu/khôi phục một bước mà không sử dụng tệp sao lưu trung gian

Các luồng đầu vào/đầu ra tiêu chuẩn cho phép thực hiện một thủ thuật thú vị với nhiều DBMS (bao gồm cả Firebird): triển khai sao lưu trực tuyến với việc khôi phục cơ sở dữ liệu từ đó ngay lập tức. Không có tệp sao lưu trung gian nào được tạo ra. Điều này thuận tiện cho việc bảo trì định kỳ và chạy thử nghiệm khôi phục (với điều kiện có một bản sao lưu khác), nhưng bạn không được sử dụng nó cho việc sao lưu tự động!

Ví dụ, nếu một lỗi đĩa nghiêm trọng xảy ra trong quá trình sao lưu/khôi phục này, cơ sở dữ liệu ban đầu có thể bị hỏng trong khi chưa có cơ sở dữ liệu mới nào được tạo. Tất nhiên, nếu bạn tính đến Vấn đề 1 và có một bản sao cơ sở dữ liệu từ lần thử trước, chỉ dữ liệu được tạo hoặc cập nhật trong cơ sở dữ liệu sau khi bản sao đó được tạo sẽ bị mất.

Khuyến nghị: không sử dụng sao lưu/khôi phục một bước ở chế độ tự động và luôn kiểm tra sự tồn tại của một bản sao đủ mới ở chế độ thủ công.

4. Lưu trữ bản sao lưu và cơ sở dữ liệu trên cùng một thiết bị vật lý

Nhiều người trong số các bạn có thể thấy buồn cười rằng lời khuyên chúng tôi đưa ra hơi trẻ con - ABC của việc sao lưu. Đúng vậy, nhưng cơ sở dữ liệu và đĩa có thể được lưu trữ trên cùng một hệ thống lưu trữ dữ liệu do sự phổ biến của môi trường ảo hóa. Và nó chắc chắn sẽ hỏng vào thời điểm không thích hợp nhất. Thêm vào đó vẫn còn những người tin rằng không có gì có thể xảy ra với dữ liệu của họ nếu họ sử dụng mảng RAID (phiên bản 1 hoặc cao hơn :)). Ngoài ra, có những người tin rằng một số máy chủ “thương hiệu” là không thể hỏng, nhưng đó là một trường hợp đặc biệt.

Khuyến nghị: không lưu trữ bản sao lưu và cơ sở dữ liệu trên cùng một thiết bị cho dù nó có vẻ đáng tin cậy đến đâu.

5. Không kiểm soát việc hoàn thành thành công quá trình sao lưu

Đây là một sai lầm khá phổ biến ở cả quản trị viên và người đứng đầu bộ phận CNTT. Nếu bạn không kiểm tra kết quả của quá trình sao lưu, bạn cũng có thể không thực hiện nó chút nào. Bạn phải nhận được thông báo về quá trình sao lưu hoàn thành thành công qua e-mail hoặc, tốt hơn nữa, qua cả tin nhắn văn bản. Và sự vắng mặt của các thông báo như vậy là dấu hiệu của một vấn đề!

Một độc giả chú ý đã đọc đến điểm này trong bài viết của chúng tôi (mặc dù còn quá sớm để trao giải thưởng cho điều đó) có thể hỏi: ‘Nhưng điều đó có liên quan gì đến ban quản lý?’ Đây là điều - quản trị viên thường cấu hình quá trình sao lưu, nhưng anh ta thấy quá nhàm chán khi kiểm tra các thông báo đặc biệt khi chúng được lưu trong một thư mục riêng vì vậy không bao giờ là thừa khi yêu cầu thêm các báo cáo về trạng thái của quá trình. Điều này liên quan đến câu hỏi ai là người đáng trách khi có vẻ như các bản sao lưu đã tồn tại, nhưng thực tế chúng không tồn tại vào thời điểm bạn cần chúng :)

! một khi kết hợp với Vấn đề 2, chúng ta không có cả cơ sở dữ liệu lẫn bản sao lưu của nó.

Khuyến nghị: sử dụng các công cụ tự động hóa sao lưu có thể giám sát các quá trình sao lưu thành công và không thành công, thông báo cho người dùng về các vấn đề và cung cấp các công cụ kiểm soát tổng hợp (điều này đặc biệt quan trọng khi bạn cần kiểm soát hàng chục và hàng trăm quá trình sao lưu trên các máy chủ khác nhau).

Khuyến nghị cho Firebird: FBDataGuard kiểm tra xem quá trình sao lưu đã hoàn thành hay chưa và gửi thông báo tương ứng. Đối với các hệ thống có nhiều cơ sở dữ liệu, có giám sát tổng hợp cấp hai với sự trợ giúp của công cụ Control Center cho phép bạn xem trạng thái của tất cả các máy chủ và cơ sở dữ liệu được giám sát trên một trang.

6. Không xác minh bản sao lưu

Việc các bản sao lưu được lưu trữ ở đâu đó không có nghĩa là chúng có thể được đọc từ đó.

Đó là lý do tại sao bạn phải thường xuyên xác minh các bản sao lưu bạn tạo để đảm bảo rằng chúng không bị hỏng hoặc bị sao chép vào /dev/null.

Khuyến nghị cho Firebird: bạn có thể tự động hóa việc xác minh sao lưu với sự trợ giúp của FBDataGuard.

7. Không kiểm tra sức khỏe cơ sở dữ liệu khi sử dụng các bản sao lưu chưa được xác minh

Thông thường, các cơ sở dữ liệu sử dụng nhiều loại sao lưu - dump, bản sao lưu thông thường, v.v. Không đi sâu vào chi tiết, chúng ta có thể phân loại thành hai loại: đã xác minh và chưa xác minh. Trong trường hợp của Firebird, đó là gbak và nbackup.

Gbak đọc toàn bộ cơ sở dữ liệu ở mức bản ghi để tạo tệp sao lưu và tạo cơ sở dữ liệu bằng cách chèn các bản ghi vào một cơ sở dữ liệu mới do đó xác minh bản sao lưu (có những cách để lỗi lọt vào bản sao được khôi phục, nhưng đó là một cách khác để quản trị viên cơ sở dữ liệu gây rối liên quan đến việc di chuyển được tổ chức kém) và chính cơ sở dữ liệu (nếu nó có thể được đọc từ đầu đến cuối, rất có thể nó không bị hỏng).

Nbackup(còn gọi là sao lưu gia tăng) tạm thời khóa tệp cơ sở dữ liệu chính để cập nhật (ở trạng thái nhất quán) và cho phép sao chép nhanh tệp cơ sở dữ liệu (toàn bộ hoặc một phần/gia tăng).

Trong trường hợp các cơ sở dữ liệu Firebird lớn (lớn hơn 500 GB), nên sử dụng nbackup để không làm chậm các thao tác của người dùng, nhưng đồng thời cần phải xác minh cơ sở dữ liệu vì các bản sao lưu chưa được xác minh mà nó tạo ra là các bản sao trang cơ sở dữ liệu và nếu một lỗi tồn tại ở mức bản ghi (do lỗi RAM) hoặc ở mức logic, một bản sao lưu chưa được xác minh sẽ chứa lỗi đó cũng như cơ sở dữ liệu gốc.

Để tránh điều này, bạn nên sử dụng xác minh trực tuyến cho cơ sở dữ liệu gốc (xác minh trực tuyến với sự trợ giúp của gfix có sẵn từ phiên bản Firebird 2.5.4 trong khi công cụ FBDataGuard của chúng tôi hỗ trợ xác minh cơ sở dữ liệu trực tuyến cho các phiên bản 1.5-2.5).

Ngoài ra, nên thực hiện sao lưu đã xác minh thỉnh thoảng (ví dụ, mỗi tuần một lần) ngoài sao lưu chưa xác minh.

Khuyến nghị cho Firebird: ngoài việc kiểm tra sức khỏe trực tuyến, FBDataGuard cho phép bạn kiểm tra quá trình khôi phục sao lưu ở chế độ tự động.

8. Không kiểm soát không gian trống cho các bản sao lưu

Thực ra, đây là một sai lầm kinh điển: nếu không đủ không gian, các bản sao lưu sẽ chiếm hết không gian trống và quá trình kết thúc với một lỗi. Lưu trữ các bản sao lưu trên cùng một đĩa với cơ sở dữ liệu có thể dẫn đến gián đoạn hoạt động của cơ sở dữ liệu và lưu trữ chúng trên đĩa hệ thống có thể dẫn đến sự cố hệ thống.

Kết hợp với Vấn đề 4, kết quả tốt nhất có thể xảy ra là khi hệ thống ngừng hoạt động vì cơ sở dữ liệu cũng cần không gian trống, nhưng nó bị chiếm bởi các bản sao lưu. Còn kết hợp với Vấn đề 5 và 2, nó khiến chúng ta lại không có cả cơ sở dữ liệu lẫn bản sao lưu của nó.

Khuyến nghị: sử dụng các công cụ sao lưu dự đoán kích thước sao lưu và cảnh báo bạn về khả năng thiếu không gian trống.

Khuyến nghị cho Firebird: FBDataGuard kiểm soát kích thước không gian trống cho mục đích sao lưu cũng như kích thước không gian trống trên đĩa chứa cơ sở dữ liệu cũng như trên đĩa hệ thống.

9. Không kiểm soát thời gian tạo bản sao lưu

Quá trình sao lưu mất 40 phút đúng nửa năm trước và sau đó đột nhiên mất ba giờ - tại sao vậy? Kích thước cơ sở dữ liệu có thể đã tăng lên hoặc một đĩa có thể đã rời khỏi mảng RAID của bạn dẫn đến hiệu suất ghi chậm hơn đáng kể và tất cả các bản sao lưu của bạn có thể sắp biến mất khỏi thế giới này. Hoặc một đồng nghiệp tốt của bạn có thể đã chạy thêm một hệ thống sao lưu cùng lúc (nhân tiện, Firebird cho phép bạn chạy nhiều quá trình sao lưu cùng một lúc mặc dù không rõ tại sao người ta lại cần điều đó). Nếu bạn không kiểm soát thời gian tạo bản sao lưu, bạn có thể bỏ qua một vấn đề mới phát sinh và bỏ lỡ cơ hội khắc phục nó trước khi nó trở nên nghiêm trọng.

Ngoài ra, nếu hệ thống sao lưu không giám sát trạng thái của các tác vụ sao lưu và chỉ chạy chúng theo lịch trình, bạn có thể dễ dàng “vượt rào”, có nghĩa là tình huống hệ thống bắt đầu một quá trình sao lưu mới trong khi quá trình trước đó chưa kết thúc.

Khuyến nghị: sử dụng các công cụ kiểm soát thời gian quá trình sao lưu!

Khuyến nghị cho Firebird: FBDataGuard kiểm soát thời gian quá trình sao lưu.

10. Sao lưu cơ sở dữ liệu trong khi đang áp dụng các bản cập nhật hệ điều hành

Đây là một vấn đề rất phổ biến đặc biệt khi kết hợp với Vấn đề 9 và bật cập nhật Windows tự động (theo mặc định, các bản cập nhật được áp dụng lúc 3 giờ sáng). Nó dẫn đến chậm lại trong trường hợp tốt nhất, nhưng nếu hệ điều hành được khởi động lại để áp dụng các bản cập nhật, bản sao lưu sẽ bị hỏng. Ít nhất, tin tốt là hệ điều hành không được cập nhật hàng ngày.

Khuyến nghị: lên lịch cập nhật hệ điều hành vào thời điểm chúng không can thiệp vào quá trình sao lưu.

11. Sao lưu cơ sở dữ liệu bằng các công cụ sao lưu tệp hoặc công cụ sao lưu máy ảo trong khi máy chủ cơ sở dữ liệu đang chạy

Nhiều quản trị viên quên rằng bất kỳ DBMS nào cũng có một bộ nhớ đệm hoạt động và phức tạp chứa dữ liệu đang được đọc và ghi trong khi các tệp cơ sở dữ liệu được mở ở chế độ truy cập ngẫu nhiên. Đó là lý do tại sao cần phải sử dụng các loại sao lưu đặc biệt thay vì chỉ sao lưu tệp (bao gồm cả việc chỉ sao chép các tệp cơ sở dữ liệu) hoặc sao lưu máy ảo. Các công cụ sao lưu tệp đọc cơ sở dữ liệu một cách tuần tự và có thể mất khá nhiều thời gian, đặc biệt là trong trường hợp cơ sở dữ liệu lớn, vì vậy không thể đảm bảo tính toàn vẹn của bản sao lưu được tạo.

Máy ảo có thể sử dụng cơ chế snapshot và Changed Block Tracking, nhưng cần phải đồng bộ hóa các bản sao lưu đã tạo để có được bản sao lưu cơ sở dữ liệu nhất quán, vì bản sao lưu sẽ không nhất quán nếu có bất kỳ thao tác ghi nào đang hoạt động với cơ sở dữ liệu tại thời điểm thu thập các khối đã thay đổi.

Đối với những người muốn sao lưu cơ sở dữ liệu của mình bằng các công cụ sao lưu tệp hoặc máy ảo, chúng tôi có thể đề xuất hai phương pháp:

1. tắt hoàn toàn các dịch vụ và tiến trình DBMS để không còn gì trong bộ nhớ cache,
2. sử dụng các agent và/hoặc script để chuyển cơ sở dữ liệu sang chế độ đặc biệt giúp an toàn khi sao chép tệp cơ sở dữ liệu một cách tuần tự. Ví dụ, có một cơ chế gọi là VSS writer cho cơ sở dữ liệu MSSQL. Khi được yêu cầu, nó chuyển cơ sở dữ liệu sang chế độ thân thiện với snapshot tại thời điểm tạo snapshot. Nếu bạn sử dụng các cơ chế dựa trên Changed Block Tracking, bạn tự mình phải đảm bảo rằng cơ sở dữ liệu nhất quán tại thời điểm đồng bộ hóa.

Nếu bạn không chuyển cơ sở dữ liệu sang chế độ thân thiện với sao lưu, bản sao cơ sở dữ liệu thu được sẽ trông giống như máy chủ đã bị khởi động lại cứng (ví dụ: mất điện). Mức độ tin cậy này hoàn toàn không đủ cho hầu hết các doanh nghiệp. Bạn có thể tìm hiểu thêm về điều này trong bài viết “Đặc điểm khi làm việc với cơ sở dữ liệu trên máy ảo”.

Đối với Firebird, cần phải khóa tệp chính của cơ sở dữ liệu bằng nbackup trước khi quá trình sao lưu bắt đầu và mở khóa sau khi quá trình kết thúc. Đối với các DBMS khác cũng có các công cụ tương tự để bật/tắt các chế độ tương ứng.

Một số quản trị viên cơ sở dữ liệu chắc chắn rằng họ có thể sao lưu cơ sở dữ liệu của mình một cách an toàn bằng các công cụ sao lưu tệp tiêu chuẩn nếu DBMS có nhật ký giao dịch, vì nhiều nhất chỉ có nhật ký này bị hỏng. Đây là một quan niệm sai lầm nguy hiểm mà các nhà phát triển DBMS không ủng hộ.

Nguồn gốc của quan niệm sai lầm này rất rõ ràng: quảng cáo mạnh mẽ của các nhà phát triển máy ảo và công cụ sao lưu thường không đề cập rằng cơ sở dữ liệu cũng như các tệp được cập nhật thường xuyên khác yêu cầu cấu hình nâng cao. Đừng tin vào những lời quảng cáo thổi phồng - không phải tất cả sữa chua đều có lợi ích như nhau.

Khuyến nghị: không sử dụng các công cụ sao lưu tệp và máy ảo mà không có các công cụ tự động hóa tương ứng cho cơ sở dữ liệu.

Khuyến nghị cho Firebird: sử dụng FBDataGuard (từ gói phân phối HQbird), nó cung cấp tích hợp với các công cụ sao lưu hỗ trợ VSS.

12. Thay thế sao lưu bằng nhân bản dữ liệu

Sao lưu dữ liệu và nhân bản dữ liệu được sử dụng để tăng độ tin cậy và ngăn ngừa mất dữ liệu, nhưng chúng vẫn khá khác nhau.

Mọi người đều thích nhân bản dữ liệu vì khả năng đồng bộ hóa dữ liệu trên một máy chủ khác với độ trễ tối thiểu, nhưng sao lưu cũng có những lợi thế không thể tranh cãi. Ví dụ, trong trường hợp xóa dữ liệu do vô tình (hoặc cố ý), nhân bản dữ liệu sẽ nhanh chóng và bình thản gửi các thay đổi đến bản sao trong khi sao lưu (đặc biệt là với các bản sao trên phương tiện chỉ đọc) miễn nhiễm với các thao tác như vậy. Cần phải nỗ lực nhất định để cấu hình cả nhân bản dữ liệu và sao lưu một cách chính xác và vẫn có khả năng xảy ra lỗi.

Khuyến nghị: Nếu bạn đã cấu hình nhân bản dữ liệu, đừng bỏ qua các bản sao lưu, hãy sử dụng cả hai.

Khuyến nghị cho Firebird: sử dụng gói phân phối HQbird Enterprise, nó bao gồm cả công cụ sao lưu và nhân bản dữ liệu.

Tóm tắt

Việc cấu hình sao lưu cho DBMS yêu thích của bạn không hề dễ dàng, vì vậy các quản trị viên cơ sở dữ liệu từ các tổ chức coi trọng dữ liệu của họ thường sử dụng các công cụ sao lưu chuyên nghiệp cho phép họ tính đến các vấn đề đã đề cập ở trên và ngăn ngừa các sự cố.

Đối với Firebird (xin thứ lỗi vì quảng cáo) có một gói tên là HQbird bao gồm FBDataGuard.

Ngoài ra, công ty của chúng tôi cung cấp hỗ trợ sao lưu và bảo trì toàn diện cho Firebird và các cơ sở dữ liệu khác, đây là lựa chọn tốt cho những người không hiểu rõ về tất cả các chi tiết kỹ thuật của việc sao lưu.

Và, tất nhiên, hãy tiếp tục nuôi dưỡng sự hoài nghi của quản trị viên, ví dụ, hãy đứng dậy và kiểm tra các bản sao lưu của bạn ngay bây giờ :)

Liên hệ

Vui lòng đặt câu hỏi nếu bạn cần: [email protected]

Muốn nhận tin tức và bài viết về Firebird? Tham gia Telegram của chúng tôi https://t.me/firebirdsql