Cách sao lưu cơ sở dữ liệu app của bạn (và khôi phục thực sự)

Để sao lưu cơ sở dữ liệu app, hãy xuất nó ra file theo lịch (với Postgres, công cụ chuẩn là pg_dump), lưu các bản sao ở nơi tách biệt với cơ sở dữ liệu, và thường xuyên khôi phục một bản vào cơ sở dữ liệu trống để chứng minh nó hoạt động. Hãy sao lưu thêm ngay trước mọi thay đổi rủi ro. Bản sao lưu mã nguồn của bạn, dù là kho GitHub hay bản xuất, không bao gồm dữ liệu.

Hướng dẫn này dành cho người vận hành một app nhỏ và muốn không còn lo mất dữ liệu. Các ví dụ dùng Postgres vì hầu hết app tạo bằng AI đều dùng nó, nhưng nguyên tắc áp dụng cho mọi cơ sở dữ liệu.

Bản sao lưu cần bao phủ những gì

Một app không chỉ là cơ sở dữ liệu. Hãy biết mỗi bản sao lưu bảo vệ phần nào.

Dữ liệu là phần không thể tạo lại. Mã nguồn có thể viết lại và cài đặt có thể nhập lại; đơn hàng của khách hàng thì không.

Bước 1: Quyết định bạn có thể mất bao nhiêu

Hai câu hỏi sau quyết định kế hoạch sao lưu của bạn:

• Bạn có thể chấp nhận mất bao nhiêu dữ liệu gần đây? Nếu bạn sao lưu một lần mỗi ngày và cơ sở dữ liệu hỏng vào buổi tối, bạn sẽ mất thay đổi của cả ngày đó. Với app thử nghiệm thì điều này ổn. Với app nhận đơn hàng thì có thể không ổn.
• App có thể ngừng hoạt động trong bao lâu khi bạn khôi phục? Cơ sở dữ liệu nhỏ khôi phục trong vài phút. Cơ sở dữ liệu lớn có thể mất lâu hơn nhiều, và bạn nên biết điều đó trước khi thực sự cần đến.

Với hầu hết app nhỏ, một bản sao lưu tự động hằng ngày cộng thêm một bản thủ công trước các thay đổi rủi ro là điểm khởi đầu hợp lý. App liên quan đến tiền hoặc dữ liệu sức khỏe nên sao lưu thường xuyên hơn, hoặc dùng cơ sở dữ liệu được quản lý có khôi phục theo thời điểm (khả năng khôi phục về bất kỳ thời điểm nào, không chỉ về bản sao lưu gần nhất).

Bước 2: Kiểm tra nhà cung cấp của bạn đã làm gì

Nhiều nhà cung cấp cơ sở dữ liệu được quản lý tự động sao lưu. Hãy tìm hiểu:

• Gói của bạn có bật sao lưu không, và chạy bao lâu một lần?
• Bản sao lưu được giữ trong bao lâu?
• Bạn có thể khôi phục về một thời điểm cụ thể, hay chỉ về ảnh chụp hằng ngày?
• Bạn có thể tải bản sao lưu về, hay chỉ khôi phục được trong hệ thống của họ?

Bản sao lưu của nhà cung cấp rất hữu ích, nhưng chúng có chung một điểm lỗi duy nhất với cơ sở dữ liệu: tài khoản. Nếu tài khoản bị đóng, bị đình chỉ hoặc dự án bị xóa, bản sao lưu có thể mất theo. Đó là lý do bạn cũng nên có bản sao của riêng mình.

Bước 3: Tạo bản dump bằng pg_dump

pg_dump xuất cơ sở dữ liệu Postgres ra file. Nó đọc một ảnh chụp nhất quán, nên app vẫn có thể chạy trong khi công cụ làm việc.

Một lệnh điển hình, dùng chuỗi kết nối mà app của bạn đã có trong biến môi trường:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Các tùy chọn có tác dụng như sau:

• --format=custom ghi một file nén mà pg_restore đọc được, và cho phép bạn khôi phục từng bảng riêng lẻ về sau. Dùng --format=plain nếu bạn muốn một file .sql dễ đọc.
• --no-owner bỏ các lệnh về quyền sở hữu, giúp việc khôi phục vào cơ sở dữ liệu khác đơn giản hơn.
• Ngày trong tên file giúp các bản sao lưu không bị lẫn lộn.

Phiên bản pg_dump nên bằng hoặc mới hơn phiên bản Postgres của cơ sở dữ liệu. Một pg_dump cũ có thể từ chối chạy.

Nếu bạn tạo app bằng AI và không muốn đụng vào dòng lệnh, bạn có thể yêu cầu:

Tạo bản sao lưu cơ sở dữ liệu của app bằng pg_dump ở định dạng custom, với ngày hôm nay trong tên file. Đừng in chuỗi kết nối hay bất kỳ bí mật nào. Khi xong, cho tôi biết tên file và dung lượng.

Bước 4: Tự động hóa

Sao lưu thủ công rất dễ bị quên. Hãy tự động hóa bằng công cụ mà thiết lập của bạn hỗ trợ:

• Sao lưu theo lịch của nhà cung cấp cơ sở dữ liệu, nếu họ có cung cấp.
• Một tác vụ theo lịch trên máy chủ hoặc dịch vụ CI, chạy pg_dump và tải file lên bộ nhớ.
• Một dịch vụ sao lưu được lưu trữ kết nối với cơ sở dữ liệu của bạn.

Dù chọn cách nào, hãy đảm bảo nó báo cho bạn khi sao lưu thất bại. Một tác vụ sao lưu đã âm thầm thất bại suốt ba tháng là câu chuyện kinh điển đáng sợ.

Bước 5: Lưu bản sao ở nơi khác

Quy tắc ngón tay cái thường được gọi là 3-2-1: ba bản sao dữ liệu, trên hai loại lưu trữ khác nhau, với một bản nằm ngoài địa điểm. Với app nhỏ, một cách làm thực tế là:

• Cơ sở dữ liệu đang chạy
• Sao lưu tự động của nhà cung cấp
• Các dump của riêng bạn trong bộ nhớ tách biệt, chẳng hạn một bucket lưu trữ đối tượng ở tài khoản khác

Ngoài ra:

• Hạn chế quyền truy cập. Bản sao lưu chứa dữ liệu của mọi người dùng. Hãy coi nó như cơ sở dữ liệu đang chạy.
• Có chính sách lưu giữ. Ví dụ: sao lưu hằng ngày trong hai tuần và sao lưu hằng tháng trong một năm. Xóa các bản cũ một cách có chủ đích, và nhớ rằng luật bảo vệ quyền riêng tư có thể yêu cầu bạn xóa dữ liệu cá nhân khi được yêu cầu.
• Không bao giờ commit bản sao lưu lên Git. Một bản dump trong kho mã là một rò rỉ dữ liệu đang chờ xảy ra.

Bước 6: Kiểm tra khôi phục

Bản sao lưu chỉ tốt bằng lần khôi phục thành công gần nhất của bạn. Ít nhất vài tháng một lần, và sau mỗi thay đổi trong quy trình sao lưu:

1. Tạo một cơ sở dữ liệu mới, trống. Đừng bao giờ khôi phục đè lên cơ sở dữ liệu đang chạy để kiểm tra.
2. Khôi phục bản sao lưu mới nhất vào đó:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Với file .sql thuần, dùng psql "$TEST_DATABASE_URL" -f backup.sql thay thế.

1. Kiểm tra mọi bảng có tồn tại, so sánh số dòng với cơ sở dữ liệu đang chạy, và xem vài bản ghi gần đây.
2. Chạy thử một bản sao của app trỏ vào đó và đăng nhập, nếu có thể.
3. Ghi lại thời gian khôi phục mất bao lâu. Đó là thời gian phục hồi thực tế của bạn.

Bước 7: Sao lưu trước các thay đổi rủi ro

Hãy tạo một bản sao lưu mới ngay trước khi:

• Chạy migration cơ sở dữ liệu làm xóa hoặc đổi tên cột
• Nhập dữ liệu hàng loạt
• Để một tác nhân AI thực hiện thay đổi lớn trên mô hình dữ liệu
• Xóa các bản ghi cũ

Trong app tạo bằng AI, tác nhân có thể thay đổi cấu trúc bảng như một phần của tính năng. Điểm kiểm tra và kiểm soát phiên bản giúp hoàn tác mã nguồn của bạn, nhưng chúng không khôi phục các dòng đã bị xóa. Một bản sao lưu ba mươi giây trước một thay đổi lớn là khoản bảo hiểm rẻ.

Những lỗi thường gặp

• Cho rằng Git hoặc bản xuất mã là bản sao lưu. Nó chỉ có mã, không có dữ liệu.
• Không bao giờ kiểm tra khôi phục. Nhiều bản sao lưu hóa ra trống, thiếu hoặc không đọc được đúng lúc cần đến.
• Giữ bản sao lưu cùng tài khoản với cơ sở dữ liệu. Một tài khoản bị xâm nhập hoặc bị đóng sẽ làm mất cả hai.
• Quên các tệp tải lên. Cơ sở dữ liệu lưu đường dẫn của tệp; hình ảnh thật nằm trong bộ nhớ.
• Để bí mật trong script sao lưu. Đọc chuỗi kết nối từ biến môi trường, không bao giờ từ nội dung script. Xem cách giữ an toàn cho API key.

Sao lưu và Mythex

Dự án Mythex có thể có một cơ sở dữ liệu Postgres riêng, và thông tin kết nối của nó được đưa vào không gian làm việc và app đã xuất bản. Tài liệu Mythex không mô tả tính năng sao lưu hay khôi phục cơ sở dữ liệu, vì vậy hãy tự lên kế hoạch: yêu cầu tác nhân tạo một dump, tải nó về và cất ở nơi an toàn, đặc biệt là trước các thay đổi lớn. Bản xuất dự án (Pro) chứa mã của bạn, với bí mật và node_modules bị loại bỏ; nó không chứa các dòng dữ liệu. Xem Database và Data ownership trong tài liệu. Để tìm hiểu thêm về chính cơ sở dữ liệu, đọc Postgres là gì.

Danh sách kiểm tra sao lưu

• Đã quyết định bạn có thể chấp nhận mất bao nhiêu dữ liệu và có thể ngừng hoạt động bao lâu
• Đã kiểm tra nhà cung cấp cơ sở dữ liệu của bạn cung cấp sao lưu tự động gì
• Bản dump của riêng bạn chạy theo lịch, và lỗi sẽ gửi cảnh báo cho bạn
• Các bản sao được lưu tách biệt khỏi cơ sở dữ liệu, với quyền truy cập bị hạn chế
• Chính sách lưu giữ đã được viết ra
• Các tệp tải lên cũng được sao lưu như cơ sở dữ liệu
• Đã kiểm tra khôi phục vào cơ sở dữ liệu trống, và đã đối chiếu số dòng
• Có sao lưu trước mọi thay đổi rủi ro

Câu hỏi thường gặp