Feature request: Atomic backup mode for single snapshot for volumes + databases
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- docker, docker-compose, python
- Lĩnh vực
- databases, devops, infrastructure
Hướng nghiên cứu
Không có tệp hoặc kiểm thử nào được nêu tên, vì vậy hãy bắt đầu bằng cách xác định phần điều phối backup và các đường dẫn hiện có của các bản dump volume và cơ sở dữ liệu. So sánh các lệnh gọi restic riêng biệt hiện tại với branch ATOMIC_BACKUP được đề xuất, sau đó xác minh rằng chế độ nguyên tử tạo một snapshot, dọn dẹp /databases khi thành công hoặc thất bại, và giữ nguyên hành vi mặc định hiện có.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
Currently, volumes and database dumps are backed up as separate restic snapshots. A volume backup produces one snapshot, and each database dump (restic backup --stdin) produces another. This was mentioned also in #106 . This means:
- A restore requires identifying and matching the correct volume snapshot with the correct database snapshot(s)
- There is no guarantee they represent the same point in time
- For applications like Nextcloud — where the data directory and database must be consistent — this creates a real risk of restoring into an inconsistent state
Proposed solution
A new environment variable ATOMIC_BACKUP (true/false, default false).
When enabled, the backup process changes from:
restic backup /volumes → snapshot 1
restic backup --stdin db1.sql → snapshot 2
restic backup --stdin db2.sql → snapshot 3
to:
docker exec db1 dump > /databases/db1/all_databases.sql (write to disk)
docker exec db2 dump > /databases/db2/mydb.sql (write to disk)
restic backup /volumes /databases → snapshot 1 (everything)
rm -rf /databases (cleanup)
The resulting snapshot contains:
/volumes/{service}/{path}/... ← volume data
/databases/{service}/all_databases.sql ← SQL dumps
A single restic restore retrieves everything needed to reconstruct the stack.
Example usage
backup:
image: ghcr.io/lawndoc/stack-back
environment:
ATOMIC_BACKUP: "true"
# ... other env vars
No changes to container labels needed — the feature is purely opt-in via the backup container's environment.
Behavior details
- Default off: When
ATOMIC_BACKUPis unset orfalse, existing behavior is fully preserved (separate snapshots,--stdinpiping). No breaking changes. - Dump to disk: In atomic mode, each database container's dump command is streamed via
docker execto a file on the backup container's filesystem under/databases/. - Single restic call: Both
/volumesand/databasesare passed to onerestic backupinvocation, producing one snapshot. - Cleanup: The
/databases/directory is removed after the backup completes (regardless of success/failure). - Error handling: If a database dump fails, the error is logged and tracked, but remaining dumps and the restic backup still run (consistent with current behavior where one DB failure doesn't block others). The process exits with a non-zero code if any step failed.
Why this matters
For any stack where application data and database state must be consistent (Nextcloud, Gitea, WordPress, etc.), atomic snapshots eliminate the gap between volume and database backups and make restores straightforward — one snapshot, one restore, guaranteed consistency.
- Ngôn ngữ chính
- Python
- Star
- 181
- Fork
- 13
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của lawndoc/stack-back
-
Maintenance QuestionĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 20/100
lawndoc/stack-back#119 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
lawndoc/stack-back#115 ·
-
Feature Request: Pre/Post-Backup Hooks and Ordered Backup ExecutionCó thể đã có người làm @muebau đã nhận 214 ngày trước. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
lawndoc/stack-back#108 · 1 bình luận ·
-
feat: Create backup/snapshot per container/compose projectCó thể đã có người làm @Abestanis đã nhận 44 ngày trước. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
lawndoc/stack-back#106 · 1 bình luận ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 48/100
lawndoc/stack-back#104 · 1 bình luận ·
Tất cả issue của lawndoc/stack-back
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
omegaup/omegaup#10353 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 5 ngày
-
bot-triaged module: LrScheduler module: optimizer triaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation glm5 llm-model
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
vllm-project/vllm-ascend#19062 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Author Page: shuai-zhao-llmĐang mởauthor-page correction
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
acl-org/acl-anthology#10496 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày