- Là công cụ sao lưu·khôi phục cho PostgreSQL, được thiết kế để mở rộng tới cả môi trường quy mô lớn, nhưng hiện đã ở trạng thái ngừng bảo trì
- Việc sửa lỗi, review PR, xử lý issue và phát triển tính năng mới đều đã dừng lại; thay vì kéo dài một cách chập chờn, dự án chọn dừng lại một cách rõ ràng
- Hỗ trợ sao lưu toàn bộ, differential, incremental cùng block-level backup, tiếp tục công việc bị gián đoạn và delta restore, cho phép chỉ lưu·khôi phục phần đã thay đổi
- Có protocol layer bao quát cả môi trường cục bộ lẫn từ xa và multiple repositories, mở rộng phạm vi vận hành qua kết nối TLS·SSH và object store tương thích S3·Azure·GCS
- Dù từng là công cụ có nhiều cơ chế đảm bảo tính toàn vẹn như checksum, chờ WAL segment, fsync, xác minh page checksum, nhưng từ nay nếu có fork xuất hiện thì sẽ phải tự xây dựng độ tin cậy riêng
Ngừng bảo trì và trạng thái dự án
- pgBackRest là công cụ sao lưu·khôi phục cho PostgreSQL, nhưng hiện không còn được bảo trì nữa
- Dự án đã dừng công việc và tuyên bố sẽ không còn dành thời gian cho sửa lỗi, review PR, xử lý issue hay phát triển tính năng mới
- Dù đã cố tiếp tục bảo trì sau khi các hình thức tài trợ và tuyển dụng trước đây chấm dứt, dự án vẫn không thể đảm bảo đủ cơ hội công việc và tài trợ để duy trì lâu dài
- Thay vì tiếp tục bảo trì một cách thất thường hoặc không trọn vẹn, họ cho rằng kết thúc rõ ràng sẽ tốt hơn
- Về sau ai đó vẫn có thể fork, nhưng khi đó sẽ được xem là dự án mới, và người bảo trì mới sẽ phải tự gây dựng độ tin cậy riêng
Các tính năng cốt lõi của dự án
- Hướng tới sao lưu·khôi phục có thể mở rộng tới môi trường PostgreSQL quy mô lớn, và phiên bản ổn định hiện tại là v2.58.0
- Được thiết kế để giảm chi phí nén vốn dễ trở thành nút thắt khi sao lưu, bằng cách tận dụng xử lý song song và các phương thức nén như lz4, zstd
- Hỗ trợ sao lưu toàn bộ, differential, incremental; không chỉ ở cấp tệp mà còn với block-level backup để chỉ sao chép phần thay đổi, giúp tiết kiệm dung lượng lưu trữ
- Có thể tiếp tục bản sao lưu bị gián đoạn, đồng thời so sánh với checksum trong manifest để xác minh lại tính toàn vẹn của các tệp đã sao chép
- Trong delta restore, các tệp không có trong bản sao lưu sẽ bị xóa trước, sau đó checksum của các tệp còn lại được đối chiếu; tệp trùng khớp sẽ được giữ nguyên và chỉ những tệp cần thiết mới được khôi phục
Vận hành từ xa và thiết kế kho lưu trữ
- Thông qua protocol layer riêng, công cụ có thể thực hiện sao lưu, khôi phục và lưu trữ archive cả trong môi trường cục bộ lẫn từ xa; kết nối từ xa dùng TLS/SSH
- Cùng protocol layer đó cũng cung cấp giao diện truy vấn PostgreSQL, cho phép làm việc mà không cần truy cập từ xa trực tiếp vào PostgreSQL, từ đó tăng cường bảo mật
- Hỗ trợ multiple repositories, nên có thể đồng thời dùng kho cục bộ để khôi phục nhanh và kho từ xa để lưu trữ dài hạn, tăng khả năng dư thừa
- Kho lưu trữ cũng có thể đặt trên S3, Azure, GCS compatible object store, nhờ đó mở rộng đáng kể dung lượng và thời gian lưu giữ
- Bản thân kho lưu trữ có thể được mã hóa, nên dữ liệu sao lưu vẫn được bảo vệ dù được lưu ở đâu
Cách đảm bảo tính toàn vẹn và nhất quán
- Tính checksum cho mọi tệp trong bản sao lưu, rồi kiểm tra lại khi restore hoặc verify
- Sau khi sao chép tệp xong, công cụ sẽ chờ đến khi tất cả WAL segment cần thiết để tạo bản sao lưu nhất quán đều tới được kho lưu trữ
- Trong mọi thao tác đều dùng fsync ở cấp tệp và thư mục để bảo đảm độ bền dữ liệu
- Nếu page checksum được bật trong PostgreSQL, thì với sao lưu toàn bộ sẽ xác minh page checksum của mọi tệp; còn với sao lưu differential·incremental sẽ chỉ xác minh các tệp đã thay đổi
- Ngay cả khi xác minh page checksum thất bại, bản sao lưu vẫn không bị dừng; thay vào đó sẽ để lại cảnh báo về trang nào thất bại, giúp phát hiện sớm page-level corruption trước khi bản sao lưu hợp lệ hết hạn
Xử lý WAL và tối ưu hiệu năng khôi phục
- Cung cấp các lệnh chuyên dụng cho WAL push/get; cả hai đều hỗ trợ xử lý song song và thực thi bất đồng bộ để tối ưu thời gian phản hồi của PostgreSQL
- WAL push tự động loại bỏ trùng lặp khi cùng một WAL segment được đưa vào nhiều lần, và sẽ báo lỗi nếu nội dung khác nhau
- WAL push bất đồng bộ giao việc truyền cho tiến trình khác và nén WAL segment song song, nên đặc biệt quan trọng với cơ sở dữ liệu có lượng ghi rất cao
- WAL get bất đồng bộ duy trì hàng đợi WAL đã giải nén ở cục bộ để có thể cung cấp ngay trước khi replay; điều này đặc biệt có lợi với kết nối có độ trễ cao hoặc kho lưu trữ như S3
- Cả WAL push và get đều so sánh phiên bản PostgreSQL và system identifier để xác nhận cơ sở dữ liệu và kho lưu trữ có khớp nhau hay không, nhờ đó giảm mạnh khả năng cấu hình sai vị trí WAL archive
Tính linh hoạt trong vận hành và khả năng tương thích
- Có thể đặt chính sách backup retention và archive expiration theo đơn vị full, differential, WAL để bao phủ phạm vi thời gian mong muốn
- Có thể lưu bản sao lưu đúng theo định dạng PostgreSQL cluster, và nếu tắt nén đồng thời bật hard link thì còn có thể khởi chạy trực tiếp PostgreSQL cluster trên snapshot của kho lưu trữ
- Cách này đặc biệt có lợi với terabyte-scale database, nơi restore truyền thống mất nhiều thời gian
- Hỗ trợ đầy đủ tablespace; khi restore có thể chuyển từng tablespace sang vị trí khác hoặc remap hàng loạt về một vị trí
- Cũng hỗ trợ liên kết tệp và thư mục, cho phép khi restore giữ nguyên vị trí gốc, remap một phần hoặc toàn bộ, hoặc khôi phục bằng cách chuyển thành tệp·thư mục thông thường
- Hỗ trợ 10 phiên bản PostgreSQL, gồm 5 phiên bản hiện còn được hỗ trợ và 5 phiên bản EOL gần đây, nhằm tạo dư địa thời gian đủ rộng cho việc nâng cấp
Tài nguyên tham khảo và tình trạng tài trợ
1 bình luận
Ý kiến trên Hacker News
Dù từng có tài trợ từ công ty, họ vẫn phải dồn cả buổi tối và cuối tuần vào dự án; sau khi Crunchy Data bị bán, họ vẫn tiếp tục duy trì và tìm một vị trí để có thể tiếp tục công việc này nhưng không thành
Vì mưu sinh, họ phải tìm kiếm những cơ hội rộng hơn, và như vậy sẽ không còn đủ thời gian cần thiết cho bảo trì, sửa lỗi, review PR và xử lý issue, nên quyết định lưu trữ kho mã
Hướng dẫn ở https://github.com/freakynit/postgre-backup-and-restore-guide, và tôi thật sự biết ơn toàn bộ thời gian cùng công sức đã được đổ vào nó
Thêm vào đó, cũng có nhiều người đã đốt tiền vào token, nên cả tiền nhàn rỗi lẫn thời gian đều giảm theo
Nếu đây là một công cụ cấp độ sản phẩm, vượt xa dự án sở thích và thực sự tạo giá trị trong môi trường thương mại, thì rõ ràng cũng có cơ hội cho một công ty vì lợi nhuận bước vào lấp chỗ trống đó
Nhưng người dùng phải trở thành khách hàng và thực sự trả tiền; không thể bền vững nếu cứ tiếp tục gửi bug report và lời phàn nàn cho những maintainer làm miễn phí
Cần một lời giải mới cho tính bền vững tài chính của FOSS, vì chỉ dựa vào quyên góp có vẻ là chưa đủ
Từ cửa hàng trong khu phố cho tới dự án nguồn mở đều như vậy
Tuy vậy, mỗi người đóng góp có thể nắm bản quyền phần của mình, nên tùy việc có ACL hay không và theo thẩm quyền pháp lý nào, có thể sẽ cần dọn dẹp quyền sở hữu và cả thỏa thuận như phân chia doanh thu
Khi còn có tài trợ từ doanh nghiệp thì mọi thứ vẫn vận hành, nhưng khi công ty bị bán và chủ mới đổi ưu tiên thì một công cụ hạ tầng 3.8k sao lập tức trở nên bấp bênh; hóa ra người dùng trước giờ không hề biết nguồn sống của công cụ backup của mình lại phụ thuộc vào chiến lược M&A của người khác
Vì vậy tôi cũng đang dần chuyển sang các file được theo dõi bằng SQLite và git
Bởi ngay cả các stack Postgres managed cuối cùng cũng được xây trên nhiều công cụ do những người mà ta không thể biết rõ tình hình tài chính của họ duy trì
Nhưng nhận định lớn hơn rằng cấu trúc tài trợ của nó mong manh thì vẫn hoàn toàn đúng
Nhân đó cũng nên nhìn lại các dự án phụ thuộc mà mình không muốn mất đi, và bắt đầu thiết lập tài trợ ngay từ bây giờ
Ai cũng nói là buồn, nhưng nếu thật sự buồn thì trước hết nên tự hỏi mình có buồn đến mức sẵn sàng quyên góp hay không
Đặc biệt, việc nó không chỉ nghiêm túc với backup mà còn với cả khôi phục và xác minh là điều rất hiếm, và tôi từng bị trả giá đắt ở chỗ làm chỉ vì xem nhẹ phần đó
Chi tiết ở https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
Vì vậy chuyện này tạo cảm giác là một mất mát khá lớn
Tôi tò mò nó so với WAL-G hay Barman thế nào
https://github.com/wal-g/wal-g
https://github.com/EnterpriseDB/barman
Mỗi đêm chúng tôi tạo một DB nightly được khôi phục bằng Barman để phục vụ đào tạo người dùng và kiểm thử, nhờ đó luôn xác minh được backup có thực sự hỏng hay không, và nhiều năm nay chưa gặp vấn đề gì
Tôi đã quay lại mảng managed Postgres sau vài năm không hoạt động, và hy vọng ngoài delta backup do wal-g cung cấp bằng cơ chế so sánh block riêng, nó cũng sẽ hỗ trợ pg17 incremental backup
Ngoài ra, rất nên dùng daemon mode
Việc công cụ cạnh tranh biến mất thì đáng tiếc, nhưng lĩnh vực này vẫn còn nhiều chỗ để cải thiện, và khi Postgres muốn chạy trên hệ thống không overcommit thì C có những điểm tốt hơn Golang
Khi đánh giá khoảng 9 năm trước, phía này hấp dẫn hơn pgBackRest nhờ đặc tính streaming PITR
Vậy giờ không biết phương án thay thế gần nhất là wal-g, barman hay databasus
Tôi nói mình chỉ đang đóng giả DBA thôi, nhưng thực ra lựa chọn này khá quan trọng
Tham khảo thêm thì tôi là DBRE
Tài liệu liên quan: https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
https://github.com/aiven-open/pghoard cũng có vẻ ổn, nhưng tôi vẫn chưa tự kiểm chứng trực tiếp
Vì vậy chuyện này càng đáng tiếc hơn, và việc đạt được mức tương đương về tính năng với công cụ tuyệt vời này có lẽ sẽ không dễ
Nếu có thể, mong đây là một quyết định còn có thể đảo ngược; nếu không, cũng mong dự án PostgreSQL có thể hấp thụ nó vào contrib
Có lẽ tác giả cũng muốn mọi người tiếp tục dùng nó cho đến khi nó thực sự không còn hoạt động, hơn là vội vàng bỏ đi ngay
Tôi không rõ có cần fork hay chỉ cần được thêm làm contributor trong kho hiện tại để tiếp quản hay không