Choosing the right backup solution

Probz

New Member
Jan 22, 2024
6
0
1
Hello,

My question is in two parts.
I host quite a few personal services at home on LXC containers, including a Photo Immich server, a Nextcloud server, and some databases that I really need to back up.
I made the mistake of doing bind mounts: I created datasets that I then mounted on the Immich and Nextcloud containers for my photos and files.
As a result, these data files are excluded from backups made via Proxmox.
What do you suggest I do to fix this problem? I could probably back up this mount point separately, but ideally I would like to centralize everything on a single backup solution. Possibly create a volume on the LXC container and copy the data. I've done some research and I don't think it's possible to “migrate” a dataset to a volume dedicated to the container.

Second question regarding the implementation of Proxmox Backup Server.
I don't have a second PC at my disposal, but I do have a disk dedicated to backup.
I see three solutions:
- Install PBS directly on the Proxmox node. I don't know if conflicts could arise when updating one of the two solutions.
- Install PBS in a privileged or non-privileged container and mount a ZFS dataset that will act as a datastore.
- Install PBS in a dedicated VM, then passthrough the disk to let the VM manage ZFS.

Can you give me advice ?

Thank.
 
Can you give me advice ?
Sure: every backup method is better than zero backups :-)

- Install PBS directly on the Proxmox node. I don't know if conflicts could arise when updating one of the two solutions.
- Install PBS in a privileged or non-privileged container and mount a ZFS dataset that will act as a datastore.
- Install PBS in a dedicated VM, then passthrough the disk to let the VM manage ZFS.
I am lucky to have several PBS' running on separate hardware, so I haven't had to make that decision. Nevertheless I have one PBS installed in parallel on PVE. And while I will not recommend that... it works as expected! The technical disadvantage is that you need to upgrade both at the very same time - there is no separation from each other, repository-wise. (This is my "first-level"-backup, run daily.)

The repository-aspect is why I probably would opt for the Container based solution, for the next iteration. (Note: I did not test that.)

The VM-solution is something I usually would prefer - for separation/isolation reasons. But in this case I would vote against it. Working with virtual disks for PBS is basically a no-go and you already mentioned passthrough. On the other side this is a complicated beast in itself as the only recommended way (from my point of view) is to pass through a controller, not a single disk. At the end you have a complex and complicated setup. It may work fine. Until it doesn't.

Especially for (data-) Backup systems I recommend KISS - keep it simple, stupid. Remember: the moment something really bad happens you need access to that backup. And you want to use the backup system easily as you already are under stress...


That's also why a PBS on the same hardware as PVE is only half a solution. If that hardware dies, both is gone!

Whatever integrated variant to choose: the very minimum is to add another, separate, external harddisk - additionally to the internal storage. On that one I would either save PBS-"synced" set of data via a PBS-datastore (complex and complicated!) or (better) simple vzdump-based backups, which are restoreable without being forced to setup a fully functional PBS first!

Of course the third level would be another copy off-site, be it at your friends house or online on computers-of-unknown-people, aka "the cloud".


As usual your-mileage-may-vary; it all depends on your own requirements and skills when something goes south...