Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

Trong thế giới đầy rủi ro của quản trị cơ sở dữ liệu và kỹ thuật độ tin cậy của trang web (SRE), có một tiên đề nổi tiếng: Bản sao lưu của Schrödinger. Trạng thái của bất kỳ bản sao lưu nào cũng là ẩn số cho đến khi bạn cố gắng khôi phục nó. Cho đến thời điểm đó, nó tồn tại ở trạng thái lượng tử: vừa hoàn hảo, vừa bị hỏng hoàn toàn.

Đối với các kỹ sư DevOps và quản trị viên cơ sở dữ liệu (DBA), việc phát hiện ra bản sao lưu cơ sở dữ liệu quan trọng bị hỏng trong một sự cố đang diễn ra là kịch bản ác mộng tồi tệ nhất. Nó biến một thao tác khôi phục thông thường thành một thảm họa mất dữ liệu. “Kẻ giết người thầm lặng” này đối với tính toàn vẹn của dữ liệu thường không bị phát hiện vì các tác vụ sao lưu thường báo cáo Exit Code 0 thành công ngay cả khi dữ liệu bên trong đã bị xâm phạm.

Trong hướng dẫn toàn diện này, chúng ta sẽ phân tích cấu trúc của sự hỏng hóc bản sao lưu, khám phá các kỹ thuật xác thực dành riêng cho từng cơ sở dữ liệu và chứng minh cách xây dựng các quy trình khôi phục tự động, an toàn cho môi trường sản xuất.

Cấu trúc của sự hỏng hóc bản sao lưu

Để phát hiện sự hỏng hóc, trước tiên bạn phải hiểu cách nó xảy ra. Sự hỏng hóc bản sao lưu thường rơi vào hai loại: vật lý (cấp độ cơ sở hạ tầng) và logic (cấp độ ứng dụng).

Hỏng hóc vật lý

Hỏng hóc vật lý xảy ra khi các bit thực tế trên phương tiện lưu trữ bị thay đổi. Điều này có thể xảy ra trong quá trình đọc từ đĩa nguồn, trong quá trình truyền tải qua mạng hoặc khi đang lưu trữ trên thiết bị đích.
* Bit Rot (Mục bit): Sự suy giảm dần dần của phương tiện lưu trữ có thể làm đảo ngược các bit một cách âm thầm.
* Lỗi truyền tải: Mặc dù TCP có các mã kiểm tra (checksum), nhưng chúng nổi tiếng là yếu (16-bit). Các môi trường có lưu lượng truy cập cao có thể gặp phải tình trạng hỏng dữ liệu thầm lặng trên đường truyền mà TCP không phát hiện được.
* Lỗi bộ điều khiển lưu trữ: Các lỗi phần cứng trong bộ điều khiển RAID hoặc cấu trúc SAN có thể ghi dữ liệu rác trong khi vẫn báo cáo thành công cho hệ điều hành.

Hỏng hóc logic

Hỏng hóc logic được cho là nguy hiểm hơn vì bản thân tệp sao lưu vẫn còn nguyên vẹn, nhưng dữ liệu bên trong nó đã bị hỏng.
* Rác vào, rác ra (GIGO): Nếu cơ sở dữ liệu trực tiếp của bạn có chỉ mục bị hỏng hoặc trang bị rách, công cụ sao lưu của bạn có thể sao chép trung thực trang bị hỏng đó. Tác vụ sao lưu thành công, nhưng việc khôi phục sẽ thất bại hoặc tạo ra một cơ sở dữ liệu bị lỗi.
* Giao dịch không hoàn chỉnh: Các bản chụp nhanh (snapshot) ở cấp độ hệ thống tệp được thực hiện mà không đóng băng I/O của cơ sở dữ liệu đúng cách (ví dụ: không sử dụng FLUSH TABLES WITH READ LOCK trong MySQL) dẫn đến các trang bị rách và trạng thái không thể khôi phục.

Phát hiện chủ động: Checksum và Băm mật mã

Tuyến phòng thủ đầu tiên chống lại sự hỏng hóc vật lý là xác thực bằng mật mã. Việc chỉ dựa vào kích thước tệp hoặc ngày sửa đổi là không đủ.

Bật Checksum ở cấp độ cơ sở dữ liệu

Các hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) hiện đại hỗ trợ checksum ở cấp độ trang. Khi được bật, cơ sở dữ liệu sẽ tính toán checksum cho mỗi trang trước khi ghi vào đĩa. Khi trang được đọc (bởi truy vấn hoặc quy trình sao lưu), checksum sẽ được xác minh.

Đối với PostgreSQL, bạn có thể bật checksum dữ liệu trong quá trình khởi tạo cụm:

# Khởi tạo cụm PostgreSQL mới với checksum đã bật
initdb --data-checksums -D /var/lib/postgresql/data

Lưu ý: Nếu bạn đã có cụm PostgreSQL, bạn có thể sử dụng tiện ích pg_checksums để bật chúng khi ngoại tuyến.

Đối với Microsoft SQL Server, hãy đảm bảo rằng PAGE_VERIFY được đặt thành CHECKSUM (mặc định trong các phiên bản hiện đại, nhưng đáng để kiểm tra trên các hệ thống cũ):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

Xác thực bản sao lưu khi lưu trữ

Khi bản sao lưu đã nằm trên mục tiêu lưu trữ, tính toàn vẹn của nó phải được xác minh bằng mật mã. Các nền tảng sao lưu doanh nghiệp như CloudSave tự động tính toán và xác minh mã băm SHA-256 của các khối sao lưu trong quá trình truyền tải và lưu trữ. Nếu bạn đang quản lý các tập lệnh tùy chỉnh, bạn phải thực hiện việc này theo cách thủ công:

# Tạo mã băm SHA-256 sau khi tạo bản sao lưu
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# Xác minh mã băm trên máy chủ lưu trữ
sha256sum -c prod_db_backup.tar.gz.sha256

Các kỹ thuật xác thực dành riêng cho cơ sở dữ liệu

Các công cụ cơ sở dữ liệu khác nhau cung cấp các công cụ gốc để xác minh tính toàn vẹn của các tệp sao lưu của chúng.

PostgreSQL: pg_verifybackup

Được giới thiệu trong PostgreSQL 13, pg_verifybackup là một bước ngoặt cho các bản sao lưu vật lý được thực hiện bằng pg_basebackup. Nó đọc tệp backup_manifest được tạo trong quá trình sao lưu và xác minh rằng tất cả các tệp đều có mặt và checksum của chúng khớp nhau.

# Chạy xác minh đối với thư mục sao lưu cơ sở vật lý
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

Nếu một bit bị đảo ngược trong bất kỳ tệp dữ liệu nào, pg_verifybackup sẽ đưa ra lỗi nghiêm trọng, cho phép hệ thống giám sát của bạn cảnh báo ngay lập tức cho nhóm DBA.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server cung cấp một lệnh gốc để xác minh tính toàn vẹn vật lý của tệp sao lưu mà không cần thực sự khôi phục nó. Nó kiểm tra các tiêu đề sao lưu và xác thực checksum của trang (nếu chúng đã được bật trong quá trình sao lưu).

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

Cảnh báo: RESTORE VERIFYONLY chỉ xác nhận rằng tệp sao lưu có thể đọc được và checksum vật lý khớp nhau. Nó không đảm bảo tính toàn vẹn logic. Để đảm bảo tính toàn vẹn logic, bạn phải thực hiện khôi phục đầy đủ và chạy DBCC CHECKDB.

MySQL / InnoDB: Percona XtraBackup

Đối với môi trường MySQL, các bản sao lưu vật lý thường được xử lý bởi Percona XtraBackup. Quá trình sao lưu bao gồm việc sao chép các tệp, nhưng bản sao lưu không nhất quán cho đến khi các nhật ký giao dịch (redo logs) được áp dụng. Giai đoạn --prepare đóng vai trò như một bước kiểm tra tính toàn vẹn tích hợp.

# Chuẩn bị bản sao lưu bằng cách áp dụng redo logs. 
# Nếu bản sao lưu bị hỏng, bước này sẽ thất bại.
xtrabackup --prepare --target-dir=/data/backups/mysql/

Tiêu chuẩn vàng: Kiểm tra khôi phục tự động

Checksum và các lệnh xác minh là cần thiết, nhưng chưa đủ. Cách duy nhất để chứng minh chắc chắn một bản sao lưu khả thi là khôi phục nó. Trong môi trường DevOps hiện đại, quy trình này phải được tự động hóa hoàn toàn.

Bằng cách coi bản sao lưu như mã nguồn, bạn có thể xây dựng quy trình CI/CD cho việc khôi phục cơ sở dữ liệu của mình. Quy trình này nên cung cấp cơ sở hạ tầng tạm thời, thực hiện khôi phục, chạy các truy vấn xác thực và xóa bỏ môi trường sau khi hoàn tất.

Xây dựng quy trình khôi phục tự động

Dưới đây là ví dụ về một tập lệnh Bash có thể được kích hoạt hàng ngày bởi cron job hoặc CI runner (như GitLab CI hoặc GitHub Actions) để xác thực bản sao lưu logic của PostgreSQL.

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] Bắt đầu kiểm tra khôi phục tự động..."

# 1. Khởi chạy container PostgreSQL tạm thời
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# Đợi PostgreSQL sẵn sàng
echo "[INFO] Đang đợi cơ sở dữ liệu khởi tạo..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. Tạo cơ sở dữ liệu đích
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. Thực hiện khôi phục
echo "[INFO] Đang khôi phục bản sao lưu..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. Chạy các truy vấn xác thực logic
echo "[INFO] Đang chạy các truy vấn xác thực..."
# Kiểm tra xem bảng người dùng có hơn 10.000 bản ghi không
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] Xác thực logic thất bại. Dự kiến >10000 người dùng, tìm thấy $USER_COUNT"
    # Kích hoạt cảnh báo PagerDuty / Slack tại đây
    exit 1
else
    echo "[SUCCESS] Xác thực logic thành công. Số lượng người dùng: $USER_COUNT"
fi

# 5. Xóa bỏ môi trường tạm thời
echo "[INFO] Đang dọn dẹp..."
docker rm -f $CONTAINER_NAME

echo "[INFO] Kiểm tra khôi phục tự động đã hoàn tất thành công."

Bạn nên xác thực những gì?

Khi thực hiện kiểm tra khôi phục tự động, đừng chỉ kiểm tra xem cơ sở dữ liệu có khởi động hay không. Hãy chạy các truy vấn xác thực dành riêng cho ứng dụng:
1. Số lượng hàng: Đảm bảo các bảng cốt lõi có số lượng hàng dự kiến (ví dụ: bảng users không được trống).
2. Dữ liệu gần đây: Truy vấn các bản ghi được tạo trong 24 giờ qua để đảm bảo bản sao lưu không bị cũ.
3. Tính toàn vẹn tham chiếu: Chạy các tập lệnh để kiểm tra các khóa ngoại bị mồ côi, điều này cho thấy sự hỏng hóc logic.

Giám sát và cảnh báo về các bất thường trong sao lưu

Việc phát hiện sự hỏng hóc trước khi thảm họa xảy ra đòi hỏi khả năng quan sát mạnh mẽ. Ngoài các trạng thái thành công/thất bại nhị phân, bạn nên giám sát siêu dữ liệu của các tác vụ sao lưu để phát hiện các bất thường.

Giám sát theo kinh nghiệm (Heuristic)

Tích hợp siêu dữ liệu sao lưu của bạn vào Prometheus và trực quan hóa nó bằng Grafana. Thiết lập cảnh báo cho các kinh nghiệm sau:
* Kích thước giảm đột ngột: Nếu bản sao lưu hàng ngày của bạn luôn là 500GB, và hôm nay chỉ là 50MB, tác vụ có thể đã hoàn thành thành công (Exit Code 0), nhưng có khả năng nó đã sao lưu một lược đồ trống.
* Bất thường về thời gian: Nếu một bản sao lưu thường mất 2 giờ mà hoàn thành trong 5 phút, có thứ gì đó đã bị bỏ qua. Ngược lại, nếu mất 10 giờ, bạn có thể bị suy giảm I/O đĩa dẫn đến hỏng hóc.
* Tích lũy WAL/Archive Log: Nếu cơ sở dữ liệu của bạn đang tạo Write-Ahead Logs (WAL) nhưng hệ thống sao lưu không lưu trữ chúng đủ nhanh, bạn có nguy cơ bị hổng trong chuỗi Phục hồi tại thời điểm (PITR).

Triển khai quy tắc 3-2-1 với kiểm tra tính toàn vẹn

Quy tắc sao lưu 3-2-1 tiêu chuẩn ngành (3 bản sao dữ liệu, 2 phương tiện khác nhau, 1 bản sao ngoại vi) chỉ hiệu quả nếu tất cả các bản sao đều được xác minh.

Đây là nơi việc tận dụng một giải pháp doanh nghiệp như CloudSave giúp giảm đáng kể chi phí vận hành. Thay vì viết và duy trì các tập lệnh bash phức tạp cho từng nút cơ sở dữ liệu, CloudSave tích hợp trực tiếp với cơ sở hạ tầng của bạn để tự động hóa vòng đời 3-2-1. Nó cung cấp lưu trữ bất biến—bảo vệ chống lại ransomware—và các lịch trình xác minh khôi phục tự động được tích hợp sẵn. CloudSave có thể tự động khởi chạy các môi trường sandbox cô lập, gắn bản sao lưu, chạy các tập lệnh xác thực SQL tùy chỉnh của bạn và báo cáo trạng thái sức khỏe về bảng điều khiển trung tâm của bạn.

Kết luận

Các bản sao lưu cơ sở dữ liệu bị hỏng là một kẻ giết người thầm lặng có thể phá hủy doanh nghiệp. Chỉ dựa vào Exit Code 0 của một tập lệnh sao lưu là một canh bạc nguy hiểm.

Để thực sự bảo vệ môi trường sản xuất của bạn, bạn phải áp dụng chiến lược phòng thủ theo chiều sâu:
1. Bật checksum ở cấp độ trang trong công cụ cơ sở dữ liệu của bạn.
2. Sử dụng các công cụ xác minh gốc (pg_verifybackup, RESTORE VERIFYONLY) ngay sau khi tạo bản sao lưu.
3. Giám sát siêu dữ liệu sao lưu (kích thước, thời gian) để tìm các bất thường.
4. Triển khai kiểm tra khôi phục tự động, tạm thời như một phần của quy trình vận hành hàng ngày.

Bằng cách chuyển từ tư duy sao lưu thụ động “cài đặt và quên đi” sang mô hình “xác thực khôi phục liên tục” chủ động, bạn đảm bảo rằng khi thảm họa không thể tránh khỏi xảy ra, dữ liệu của bạn đã sẵn sàng, đáng tin cậy và có thể khôi phục hoàn toàn.

Danh mục