Comment on Filesystem and virtualization decisions for homeserver build
WASTECH@lemmy.world 2 weeks ago
I have been using TrueNAS for about 3 years now and couldn’t be happier. It can do all of the backup stuff for you as well. I’m not sure if you would be able to use the key server for booting though, but I believe it would check all the other boxes. I don’t currently run VM’s on it (only docker), so not sure what it can do for VM backups.
Regardless of what you end up going with, I’m curious why you are saying you need to shut down the VM to back it up? I’m not familiar with how you are running the VM so not sure if it’s a limitation of the hypervisor, but I would think as long as you can snapshot the disk, you could just back up the snap. It would be crash-consistent rather than application-consistent, but for a backup scenario that should generally be fine.
thecoffeehobbit@sopuli.xyz 2 weeks ago
Right, so my aversion to live backups comes initially from Louis Rossmann’s guide on the FUTO wiki where he mentions it’s non trivial to reliably snapshot a running system. After a lot of looking elsewhere as well I haven’t gotten much hints that it would be bad advice and I want to err on the side of caution anyway. The hypervisor is QEMU/KVM so in theory it should be able to do live snapshots afaik. But I’m not familiar enough with the consistency guarantees to fully trust it. I don’t wanna wake up one day to a server crash and trying to mount the backed up qcow2 in a new system and suddenly it wouldn’t work and I just lost data.
It won’t matter though as I’ll just place all the important data on the zpool and back that up frequently as a simple data store. The VMs can keep doing their nightly shutdown and snapshot thing.
WASTECH@lemmy.world 2 weeks ago
I work for a medium size enterprise as a backup architect. All of our backups are crash consistent and we’ve never had an issue.
Windows has an easy way of dealing with this in the form of VSS. As long as the application supports it, VSS can prepare the system and application for a backup, putting it in an application-consistent state before the snapshot is taken. Unfortunately, there is no equivalent for Linux. The best you can do is pre-freeze and post-thaw scripts to put the application/OS in a backup-ready state. Really though, I wouldn’t worry too much about it. Unless you are running an in-memory database, you really don’t need to worry about application consistency. If you are running an in-memory database, take database level backups (can also be done with pre-freeze/post-thaw scripts) and back up the backups.
Just remember to test whatever solution you end up going with, and make reminders to frequently re-test your backups. You never know what might change in a year’s time, so re-testing periodically is a good way to make sure everything is still functioning properly and make sure your data is still protected. And testing needs to be more than just making sure the VM powers on. Make sure the application can start up and function properly before calling it a successful test.
thecoffeehobbit@sopuli.xyz 2 weeks ago
Always a good reminder to test the backups, no I would not sleep properly if I didn’t test them :p
Aiming to keep it simple, too many moving parts in the VM snapshots / hard to figure out best practices and notice mistakes without work experience in the area, so I’ll just backup the data separately and call it a day. But thanks for the input! I don’t think any of my services have in-memory db’s.