Backups and Disaster Recovery

[es5445]

Really loving the idea of the project and how quickly features are being added. I have a question about backups. I've messed with creating a backup of a subvolume and restoring it to the same NASty instance and that has all been straightforward. What I'm not seeing is an option to restore a backup that was created with a different instance.

Let's say I have appdata for my docker containers backed up to some S3 storage, and I have a disaster that takes out my entire NASty machine. If I re-installed NASty on another machine, I would expect to be able to restore that appdata backup that was created in a different NASty instance. I don't see an option in the web GUI that would allow this. On my primary NAS I currently utilize Backrest (GUI for restic) and that functionality does exist.

LLMs tell me NASty's backup system is based on rustic and should be functionally similar/identical to restic. Is there anything on the road map to add this sort of functionality to the web GUI?

[fenio]

Great question, and you haven't missed a button — this is a real gap. Worth untangling two different mechanisms first, because they explain what you saw:

• Local subvolume snapshots (what you restored to the same instance): these are bcachefs snapshots living on the box itself. Fast, same-instance, no repo involved.
• Rustic backups (your appdata → S3): a separate system (rustic_core, restic-compatible) that writes to an external repo. This is the disaster-recovery path.

On the rustic side, NASty currently supports running backups, checking a repo, and listing its snapshots — but there is no restore operation yet, cross-instance or otherwise. So DR restore genuinely isn't built, not just hidden.

The encouraging part: the foundation is most of the way there, and — importantly — restoring a different instance's backup is barely harder than restoring your own. Rustic repos are self-contained and instance-independent (that's the whole point of restic/rustic — the repo isn't tied to the box that made it), and NASty's backup-profile model already carries what's needed to point at an existing repo (target + password), with snapshot listing already reading whatever repo you point it at. So the missing piece is narrowly the restore side. Once that lands, your scenario becomes: fresh install → add a profile pointing at the old S3 repo → its snapshots appear → restore — the "different machine" part comes for free.

It's very much roadmap-worthy. To shape it well, a few questions:

1. When you reach for restore in Backrest today, is it usually whole-snapshot restore (pull everything back to a path) or browse-and-pick individual files/folders? That decides where the WebUI effort goes first.
2. Restore in place (back to the original path) vs. to an alternate location you then move from — which do you lean on?
3. For the DR flow specifically: would "re-add the repo by pointing at its S3 target + entering the repo password, then browse its snapshots" match how you'd expect to recover, or were you picturing something more automatic (e.g. NASty remembering repos across a reinstall)?
4. Anything about Backrest's restore UX you specifically want (or want to avoid)?

Answers here will directly shape the feature — thanks for the detailed writeup.

[es5445]

It seems I misremembered the backup and restore I performed. I didn't restore a local snapshot and I didn't restore through the built-in backup system as you mentioned it's not possible. I actually installed backrest in docker on nasty and configured a backup to s3 storage. I then wiped the backrest instance and tested recovering my backup. I started testing Backrest on nasty because I was familiar with it and was confused about restore functionality with the built-in system.

I'll attempt to answer your questions.

1. For my usage being able to pull everything back is most important. Being able to choose individual files and folders would be a nice to have but isn't critically important to me.
2. Again both options would be nice, but for my expected flow restoration to an alternative path would be best.
3. The first part of this is what I would expect. That's how backrest works and it's as much as could realistically be expected. I don't see how two isolated installations of NASty could remember across installs. Unless you're suggesting this would be baked into the /var/lib/nasty config and the expectation would be that that is restored first on a fresh install. If so, that isn't important to me.
4. A carbon copy of the backrest restore system would be great. There's nothing I found missing but I also don't see anything particularly unnecessary.

[fenio]

That clears it up perfectly — thanks. So to confirm the picture: you were running Backrest-in-Docker on NASty and testing restore through that, which is exactly the workaround the built-in backup should make unnecessary. Good — no confusion on your end, just a real missing feature.

Your answers give us a crisp target, and it's a well-bounded first cut:

• Whole-snapshot restore to a path you choose (alternate location), as the priority.
• The disaster-recovery flow you described works for free once restore exists: on a fresh box you add a backup profile pointing at the old S3 repo (target + password) — NASty can already do that and already lists the repo's snapshots — then restore. Rustic repos are instance-independent, so "different machine" needs nothing special, and you're right that no cross-install memory is needed.
• Backrest parity as the north star for the restore UX.

We'll treat file/folder-level picking and in-place restore as follow-ups, per your own ranking.

Next step on our side is a short design pass on the restore mechanics (rustic's restore API, where restores are allowed to write, and streaming progress to the UI), then implementation. I'll link the work back here so you can follow along — and when it's ready, testing your real S3-repo DR scenario against it would be hugely valuable, since that's the exact thing this is for.

Really appreciate the clear answers.

[fenio]

@es5445 — restore just landed: #635.

You can now restore a whole snapshot from the Backups page: pick a snapshot → choose a destination filesystem (+ optional subfolder) → restore, tracked with a progress bar. And because rustic repos are instance-independent, this covers the disaster-recovery case you raised directly — point a fresh box at your existing repo (S3/REST/local; target + password are already supported), list its snapshots, and restore onto it. No Backrest needed.

A couple of design choices worth calling out:

• Restores are jailed under /fs, and restoring into a non-empty folder requires ticking "Overwrite existing files" — rustic merges/overwrites colliding files and never deletes extras, so a restore can't wipe unrelated data.
• File/folder-level restore within a snapshot is a deliberate follow-up; v1 does whole-snapshot.

Your cross-instance S3 scenario is exactly the acceptance test we can't fully reproduce in the lab, so if you get a chance to try the branch against your repo, that feedback would be gold. Thanks for the nudge on this one.