- Là công cụ sao lưu/khôi phục cho PostgreSQL được thiết kế để mở rộng tới cả các môi trường quy mô lớn, nhưng nay đã 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 thất thường, dự án chọn dừng hẳn một cách rõ ràng
- Hỗ trợ sao lưu full, differential, incremental và block-level backup, tiếp tục công việc bị gián đoạn, cùng delta restore để 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
- Đây từng là công cụ có hệ thống đảm bảo toàn vẹn rất rộng, như checksum, chờ WAL segment, fsync, xác minh page checksum; nhưng từ nay dù có fork xuất hiện thì cũng sẽ phải tự xây lại độ tin cậy riêng
Chấm dứt 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 nay không còn được bảo trì nữa
- Dự án đã ngừng công việc và tuyên bố sẽ không còn dành thời gian cho việc sửa lỗi, review PR, xử lý issue hay phát triển tính năng mới
- Ngay cả sau khi các hình thức tài trợ và tuyển dụng trước đó chấm dứt, tác giả vẫn cố tiếp tục bảo trì, nhưng không thể đảm bảo đủ cơ hội công việc và tài trợ để duy trì dự án
- Thay vì tiếp tục bảo trì một cách thất thường hoặc không đầy đủ, 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à một dự án mới, và người bảo trì mới sẽ phải tự xây dựng độ tin cậy riêng
Các tính năng cốt lõi của dự án
- Nhắm 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 full, differential, incremental; không chỉ ở mức file mà còn có 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 đối chiếu với checksum trong manifest để xác minh lại tính toàn vẹn của các file đã sao chép
- Với delta restore, hệ thống sẽ xóa trước các file không có trong bản sao lưu rồi đối chiếu checksum của các file còn lại; file trùng khớp sẽ được giữ nguyên và chỉ khôi phục những file cần thiết
Vận hành từ xa và thiết kế kho lưu trữ
- Thông qua protocol layer riêng, có thể thực hiện các tác vụ sao lưu, khôi phục, lưu trữ archive ở cả môi trường cục bộ và 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, qua đó tăng cường bảo mật
- Hỗ trợ multiple repositories, cho phép dùng song song kho cục bộ để khôi phục nhanh và kho từ xa để lưu trữ dài hạn, tăng tính dư thừa
- Kho lưu trữ cũng có thể đặt trên object store tương thích S3, Azure, GCS, giúp 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 toàn vẹn và tính nhất quán
- Tính checksum cho mọi file trong bản sao lưu và kiểm tra lại khi restore hoặc verify
- Sau khi sao chép file xong, hệ thống sẽ chờ cho đến khi tất cả WAL segment cần thiết đến được kho lưu trữ để đảm bảo bản sao lưu ở trạng thái nhất quán
- Mọi thao tác đều dùng fsync ở cấp file và thư mục để đảm bảo độ bền dữ liệu
- Nếu PostgreSQL bật page checksum, thì với sao lưu full sẽ xác minh page checksum của mọi file; còn với sao lưu differential·incremental thì chỉ xác minh các file đã thay đổi
- Ngay cả khi việc xác minh page checksum thất bại, bản sao lưu cũng không bị dừng, nhưng hệ thống sẽ cảnh báo trang nào thất bại để có thể phát hiện sớm page-level corruption trước khi bản sao lưu hợp lệ hết hạn
Tối ưu xử lý WAL và hiệu năng khôi phục
- Cung cấp 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 sẽ tự động loại bỏ trùng lặp nếu cùng một WAL segment được đưa vào nhiều lần, và sẽ phát sinh 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 song song các WAL segment, điều này đặc biệt quan trọng với các cơ sở dữ liệu có lượng ghi rất cao
- WAL get bất đồng bộ duy trì WAL queue đã giải nén ở cục bộ để có thể cung cấp ngay trước khi replay; lợi ích này đặc biệt lớn với các 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 không, từ đó giảm mạnh khả năng cấu hình sai vị trí WAL archive
Tính linh hoạt vận hành và khả năng tương thích
- Có thể thiết lập 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; nếu tắt nén và bật hard link thì thậm chí có thể khởi động trực tiếp PostgreSQL cluster trên snapshot của kho lưu trữ
- Cách làm 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ợ link của file và thư mục, nên khi restore có thể giữ nguyên vị trí ban đầu, remap một phần hoặc toàn bộ, hoặc khôi phục bằng cách chuyển thành file/thư mục thường
- Hỗ trợ 10 phiên bản PostgreSQL, bao gồm 5 phiên bản hiện còn được hỗ trợ và 5 phiên bản gần đây đã EOL, giúp có đủ dư địa thời gian cho việc nâng cấp
Tài nguyên tham khảo và tình trạng tài trợ
2 bình luận
Về việc này đã có cập nhật.
Ý 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