Backrest is set up, but I have no idea how I'd actually restore if the box dies
UGREEN DXP4800 Plus on UGOS. All my Docker containers sit on volume2 (SSD). Backrest backs up the whole of volume2 to an external USB drive hanging off the NAS, and before each run it stops every container except itself, then starts them all again once it's…
UGREEN DXP4800 Plus on UGOS. All my Docker containers sit on volume2 (SSD). Backrest backs up the whole of volume2 to an external USB drive hanging off the NAS, and before each run it stops every container except itself, then starts them all again once it's done. I went with Backrest rather than UGREEN's own backup app because I'm not putting my data in a vendor format that only works for as long as I stay on their hardware. And yes, I know one USB drive sitting next to the NAS isn't 3-2-1. Offsite is next on the list, and I'd sooner buy a second NAS and put it at a family member's place than pay a cloud subscription forever, because I want to stay in charge of my own data. But none of that helps me if I can't restore in the first place, which is what I'm actually stuck on. I've been through a pile of tutorials and the setup side is clear enough. Every guide stops at "backup configured, job done" and nobody shows what you do when it goes wrong. So if the board or the PSU dies tomorrow and I buy new hardware, is it really just a case of setting it up, installing Docker, installing Backrest, pointing it at the existing restic repo on the USB drive, restoring volume2 to the same path and starting the containers again? Or is there more to it than that. The bit I'm least sure about is that stop/start cycle. A lot of these containers have a database behind them, so is stopping everything enough to get a clean snapshot, or should I be dumping the DBs instead and skipping the downtime? And I'm wondering whether there's anything outside volume2 worth grabbing as well. I'll do a trial restore before I trust any of this, but I'd like to know what the procedure is meant to look like first, otherwise I can't tell the difference between a restore that worked and one that only looks like it did. Everything in my house runs off this box and I'm about to move the family off iCloud Drive onto my own Nextcloud, so I'm not guessing at this one. Thanks.
Collected discussion
Expand the replies to this comment to learn how AI was used in this post/project.
Yes, I did. Good to know that stopping containers is fine, because I have a lot of containers running to dump the database from them every time. That's going to be so much work every time, so I'm trying to automate this.
I use the standard Docker app that is installed on my UGREEN NAS. It created a volume on its own and stores all compose files there; I store all configurations and the database in the same folder. All data, such as images and videos, I store on my hdd’s (volume1). If I read it all like that, I think I have everything set up correctly; thanks for your explanation!
It was pretty late last night when I read your post and completely glossed over the fact that you're running docker on the nas itself. Apologies. You talked about not wanting to be locked into someone else's subscription in your post. I see nas hardware as the same situation. Have you ever tried running docker on a Linux box? You can get small form factor machines for cheap/free if you look around. That might be much easier hardware to replace if something goes wrong. Not knocking your setup, and you do you, just a friendly suggestion
I took all of that into the backup plan, thank you for your explanation.
I just replied to a message from another person, but I was also thinking about that: I wanted to use an old laptop, but maybe a virtual machine is still a bit easier. Thanks for the tip.
Is it important that I take the entire Backrest folder with me, or is it sufficient to run the compose again and add the external usb?
Will be a nice task for the weekend. I think I will really be sure then if I have set everything right and once that all works, I will buy a second NAS so that I can follow the full 3-2-1 back-up strategy.
that's the right order. before buying the second NAS, i'd do one restore from the USB onto the laptop with the NAS totally out of the loop: fresh Docker install, same compose/env files, point Backrest at the repo, restore one simple app, then one database-backed app. if both work and your written steps are clear enough to follow cold, the second NAS becomes an offsite capacity/redundancy decision instead of a leap of faith.
Not yet, I’ll let you know when I’ve done it.
Sounds good, curious to hear how it goes.
I also run backrest, and I've restored to the same running machine. This is great when I screw up a container trying to update it or something. I do not stop any containers by any means before the backup happens, and I don't think backrest does this either but I could be wrong here. I've never had any issue restoring volumes that include databases. Here's my setup: Server PC running docker and all containers. Compose files are in /opt/docker/stacks/container name Volumes (including databases) are in /opt/docker/volumes/container name I store the backrest volume outside of this directory in /opt/backrest I don't know if trying to back up itself would be a problem, but I don't need that backed up anyway I have a nas mounted via NFS at /mnt/nas In backrest I create the repo on the nas directory and have the password memorized. This is what is used to encrypt the backups. You need this for a new instance to decrypt the backups and restore anything. Whether it's on the same machine or a brand new machine shouldn't matter. I back up my entire /opt/docker directory to the mounted nas. In backrest I can browse the snapshot and restore either the entire docker directory, just the stacks or volumes directories, out even a single particular volume (browse the snapshot, find what you're trying to restore, click the 3 dots beside it, restore). For example I just restored the freescout ticketing app the other day. I just needed the volume so I stopped the container and deleted the current volume and restored from backup. When I did this backrest created /opt/docker/volumes/freescout-backup-string-of-numbers/freescout I had to set permissions 755 recursively to the base directory, moved the freescout directory up one level, deleted the backup folder that was restored, and started the container. It worked perfectly. In a total hardware failure, yes, installing docker, spinning up backrest, and pointing it to your original repo with the password should be enough to get you back up and running
stopping containers is fine for restic but db dumps are safer if you can spare the time, also grab your docker compose files if they arent already on volume2
the only way to know your restore works is to actually do one before you need to. spin up a throwaway VM or an old box, install docker and backrest, point it at a copy of the restic repo and restore volume2 into it. a backup you have never restored from is just a hope, and finding out the repo password or a missing compose file is wrong at 2am with dead hardware is how people actually lose everything.
For a full restore, install Backrest fresh on a new machine, point it at the same external USB with the same repo path (and encryption key if you set one), and use the Restore tab to pick a snapshot and extract it to your new volume path — then bring your compose stack back up. The main thing to add now: keep a copy of your compose files somewhere separate from volume2 (the USB itself or a git repo), so you're not hunting for them when the NAS is already dead.
that old laptop test is exactly the right move. i'd make the restore drill small and repeatable: copy the compose/env files plus one app's data folder onto the laptop, run docker compose up, and prove you can log in with the expected data. then write down the restore steps in the same folder as the backup. the hidden gotchas are usually env files, docker networks, bind-mount paths, and databases that looked copied but were mid-write. once one app restores cleanly, add the nastiest database-backed app next.
Did you end up running the restore test on the old laptop? Curious what broke or surprised you once you tried it from a clean setup.
This comment was deleted.