Appetite for a pre-update data layer (DB dump + volume snapshot) + coordinated data rollback?

[canblmz1]

Hi @dkorecko — PatchPanda's failure handling is already ahead of most updaters: reverting the compose/.env to the previous version on a failed update, plus the AI release-note / breaking-change summaries. Nice work.

The piece I don't see covered (and couldn't find requested — the closest are the hook threads in #89 and #134) is the data layer. On a failed update, reverting the compose file still leaves you with whatever the migration did to your database/volumes. For stateful apps (Immich, Nextcloud, Paperless…) a bad migration can corrupt data that a file/image revert can't undo.

Before I build anything, I wanted to ask your direction:

Would a pre-update data safety net fit PatchPanda's vision — snapshotting just the DB (pg_dump / mysqldump / sqlite) + config volume before recreate, and on a failed healthcheck rolling back compose + data together? Or is data deliberately out of scope, left to the pre/post hooks discussed in #89 / #134?

Depending on your appetite I could either:

1. Contribute it — e.g. wired into the pre/post-hook mechanism you're already discussing, or
2. Build a standalone CLI that PatchPanda / WUD / Tugtainer can call as an "apply/data" layer.

Which direction fits how you see the project? Happy to prototype whichever you prefer. Thanks!

[dkorecko]

Hey!

Securing the data is definitely something I would love to have in the main app, so I love the initiative. I would probably err on the side of caution and make this something the user has to toggle, probably giving an option to set it as a global env variable, but also a per-container/stack override. Maybe we don't even have to snapshot the DB, maybe the trade-off could be we shut the container down, snapshot the volumes, then bring it back up and revert all of it when there's an issue? Then we wouldn't need to handle logic for detecting the database and maintaining the logic for the dumps ourselves?

Regardless, happy to hash this out and the contribution would be very welcome :)

Let me know what you think!

[canblmz1]

Awesome, thanks for the quick and thoughtful reply — I'd be happy to make this our first contribution to PatchPanda. Count me in.

I really like your cold-snapshot framing, and I think it's the right call: stopping the container before snapshotting sidesteps the whole "torn/inconsistent copy" problem, so a plain volume snapshot becomes a consistent, restorable backup — no need to detect the DB engine or maintain per-database dump/restore logic. That removes the biggest maintenance burden. Agreed on making it opt-in via a global env var + a per-stack/container override too.

Two small refinements I'd suggest so it holds up on real setups:

1. Fast-path for big volumes. A cold copy of a large volume means real downtime + temporary 2x disk. Where the filesystem supports it we can use copy-on-write (cp --reflink=auto on btrfs / XFS-with-reflink, or a native ZFS/btrfs snapshot) to make the copy near-instant and space-cheap, and fall back to a full copy on ext4. Keeps the "no DB logic" simplicity while staying usable for people with large data volumes.
2. Volume include/exclude. We'll want to avoid snapshotting large media volumes (e.g. an Immich upload volume that's terabytes). Default to the stack's named volumes, with an exclude list (label or config) so users can skip the heavy ones.

A few design questions before I open a PR, so I build it the way you'd want it merged:

• Wiring: should this be a first-class step in the update flow, or built on top of the pre/post-hook mechanism from Pre/post hooks (or git integration?) #89 / Post update hook #134?
• Revert trigger: what should count as "an issue" — container fails to start, exits non-zero, or an (optional) healthcheck that goes unhealthy within a timeout? I'd suggest making it healthcheck-aware when the container defines one, and falling back to start/exit status otherwise.
• Snapshot storage + retention: where should snapshots live, and how many should we keep before cleanup?
• Contribution flow: would you prefer a short design note/issue first, or a small draft PR to react to? Any CONTRIBUTING notes or a branch you'd like me to target?

Happy to start small and iterate. Excited to work on this!