Sheet happens. Ở bài trước tụi mình cũng đã học quy trình từng bước để phục hồi database hoàn toàn sau khi bị crash. Nhưng đời mà, lúc nào cũng có bất ngờ. Nếu backup của bạn bị hỏng thì sao? Đến lúc phải xử lý vụ này rồi đó.
Nên để résumé ở đâu thì tốt hơn?
Đùa thôi. Giờ mình sẽ bàn về mấy vấn đề kỹ thuật. Nhưng nhớ là, trong mỗi câu đùa đều có chút sự thật nha :)
Phân tích backup bị hỏng
Backup bị hỏng — giống như file đồ án tốt nghiệp của bạn không mở được ngay trước ngày nộp. Triệu chứng cũng na ná vậy:
- Lỗi khi thử phục hồi: khi chạy
pg_restorebạn có thể thấy lỗi kiểu như:
pg_restore: [archiver] input file does not appear to be a valid archive
- Một phần dữ liệu bị thiếu hoặc file có kích thước không đúng (ví dụ, tự nhiên nhỏ xíu hoặc bằng 0).
- File SQL đã giải nén bị đứt đoạn, có ký tự lạ hoặc có đoạn trống.
Backup bị hỏng có thể do nhiều lý do:
- Bị ngắt quá trình backup (ví dụ, mất điện hoặc tắt máy đột ngột).
- Chuyển file sai cách (lỗi khi copy qua USB hoặc qua mạng).
- Lỗi phần cứng (ổ đĩa, RAM, lỗi RAID).
- Lỗi cấu hình hệ thống hoặc tool tạo backup.
- Virus, malware và tất nhiên, cú click nhầm định mệnh.
Khôi phục dữ liệu từ backup bị hỏng
Nếu file bị hỏng thì cũng chưa phải là hết hy vọng. Đôi khi vẫn cứu được chút gì đó. Cùng xem vài cách thử nhé.
Thử phục hồi bằng pg_restore
Nếu file được tạo bằng pg_dump với format custom hoặc directory, thử chạy lệnh phục hồi với flag --ignore-errors. Ví dụ:
pg_restore --dbname=your_database --ignore-errors backup_file.dump
Flag này bảo tool bỏ qua lỗi khi phục hồi và tiếp tục. Dữ liệu ở chỗ bị hỏng sẽ mất, nhưng ít ra vẫn cứu được phần nào.
Nếu chạy được, bạn nên kiểm tra kỹ dữ liệu đã phục hồi và ghi chú lại xem thiếu gì.
Dùng dữ liệu còn lại
Giả sử bạn có backup ở dạng text SQL. Thử mở nó bằng editor xịn xịn (ví dụ Visual Studio Code hoặc Notepad++) để xem nó bị đứt ở đâu. Nếu file đọc được và phần lớn câu lệnh SQL còn nguyên:
- Xoá phần bị hỏng ở cuối file.
- Chạy phần còn lại bằng tay hoặc dùng lệnh
psql:
psql -U username -d database_name -f partial_backup.sql
Đọc file dạng custom
Nếu backup của bạn ở dạng custom, có thể thử extract từng phần nội dung:
pg_restore --list backup_file.dump > file_list.txt
Lệnh này sẽ tạo danh sách tất cả object trong backup. Sau đó bạn có thể thử phục hồi từng phần (ví dụ table hoặc schema) bằng lệnh:
pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump
Bằng cách sửa file_list.txt, bạn có thể loại bỏ phần bị hỏng khỏi quá trình phục hồi.
Thử phục hồi qua archive log (WAL)
Nếu bạn dùng backup incremental hoặc differential (ví dụ qua pg_basebackup), khả năng cao bạn có archive log (file WAL). Chúng lưu lại mọi thay đổi từ lần backup trước. Để phục hồi dữ liệu, bạn có thể:
- Tìm backup nguyên vẹn gần nhất (ví dụ full backup).
- Chỉ cho PostgreSQL biết chỗ chứa file WAL:
restore_command = 'cp /path/to/wal_directory/%f %p'
- Chạy phục hồi.
Dùng tool bên ngoài
Đôi khi có thể giảm thiểu hỏng backup bằng tool phục hồi file. Một tool khá phổ biến là ddrescue. Ví dụ:
ddrescue --force backup_file.dump recovered_dump.file
Tool này sẽ cố gắng cứu càng nhiều dữ liệu càng tốt và tạo bản copy mới.
Phòng tránh backup bị hỏng
Đúng là làm việc với file hỏng thì stress thật. Nghĩ thử xem làm sao để tránh mấy vụ này nhé.
Lưu backup ở nhiều nơi
Trong project, backup luôn phải theo rule "đừng bỏ trứng vào một giỏ". Nên lưu backup ở nhiều chỗ:
- Trên server local.
- Trên cloud (Amazon S3, Google Cloud Storage hoặc đơn giản như Dropbox).
- Trên ổ cứng ngoài (nếu bạn muốn siêu an toàn).
Kiểm tra định kỳ backup
Dân IT có câu: "Backup mà chưa test thì không phải backup". Thường xuyên kiểm tra backup bằng cách test phục hồi. Cụ thể:
- Upload backup lên server test.
- Phục hồi dữ liệu từ đó.
- Kiểm tra xem dữ liệu có ổn không.
Dùng checksum
Khi tạo backup, hãy tạo checksum cho file (ví dụ dùng MD5 hoặc SHA256):
md5sum backup_file.dump > backup_file.md5
Khi phục hồi, so sánh checksum hiện tại với bản gốc:
md5sum -c backup_file.md5
Như vậy bạn sẽ biết trước nếu file bị hỏng.
Ví dụ phục hồi từ backup bị hỏng
Xem thử vài case thực tế nhé.
Case 1. Lỗi khi chuyển file
Bạn chuyển backup qua FTP, nhưng phát hiện file nhỏ hơn dung lượng mong đợi. Bạn dùng pg_dump ở dạng text, nên:
- Mở file bằng editor.
- Xoá phần dữ liệu bị hỏng.
- Phục hồi phần còn lại bằng
psql.
Case 2. Mất một phần dữ liệu trong WAL
Server của bạn dùng backup incremental và file WAL archive. Đột nhiên một số file biến mất. Nhưng bạn vẫn phục hồi được dữ liệu nhờ pg_basebackup và mấy file WAL còn sót lại, bằng cách chỉ đường dẫn trong config phục hồi.
Nhớ nha, backup không chỉ là tạo bản copy mà còn phải kiểm tra nó nữa. Đừng đợi đến ngày tận thế mới phát hiện backup của mình vô dụng. Nếu backup bị hỏng, đừng hoảng: PostgreSQL có nhiều cách để cứu dữ liệu. Quan trọng là phải bình tĩnh và làm từng bước!
Còn nếu không cứu được gì nữa — đọc lại mục đầu tiên của bài này đi nha.
GO TO FULL VERSION