Stop services while creating snapshots during backup?
Stop services while creating snapshots during backup?
It's fairly obvious why stopping a service while backing it up makes sense. Imagine backing up Immich while it's running. You start the backup, db is backed up, now image assets are being copied. That could take an hour. While the assets are being backed up, a new image is uploaded. The live database knows about it but the one you've backed up doesn't. Then your backup process reaches the new image asset and it copies it. If you restore this backup, Immich will contain an asset that isn't known by the database. In order to avoid scenarios like this, you'd stop Immich while the backup is running.
Now consider a system that can do instant snapshots like ZFS or LVM. Immich is running, you stop it, take a snapshot, then restart it. Then you backup Immich from the snapshot while Immich is running. This should reduce the downtime needed to the time it takes to do the snapshot. The state of Immich data in the snapshot should be equivalent to backing up a stopped Immich instance.
Now consider a case like above without stopping Immich while taking the snapshot. In theory the data you're backing up should represent the complete state of Immich at a point in time eliminating the possibility of divergent data between databases and assets. It would however represent the state of a live Immich instance. E.g. lock files, etc. Wouldn't restoring from such a backup be equivalent to kill -9 or pulling the cable and restarting the service? If a service can recover from a cable pull, is it reasonable to consider it should recover from restoring from a snapshot taken while live? If so, is there much point to stopping services during snapshots?
You start the backup, db is backed up, now image assets are being copied. That could take an hour.
For the initial backup maybe, but subsequent incrementals should only take a minute or two.
I don't bother stopping services, it's too time intensive to deal with setting that up.
I've yet to meet any service that can't recover smoothly from a kill -9 equivalent, any that did sure wouldn't be in my list of stuff I run anymore.
It depends on the dataset. If the dataset itself is very large, just walking it to figure out what the incremental part is can take a while on spinning disks. Concrete example - Immich instance with 600GB of data, hundreds of thousands of files, sitting on a 5-disk RAIDz2 of 7200RPM disks. Just walking the directory structure and getting the ctimes takes over an hour. Suboptimal hardware, suboptimal workload. The only way I could think of speeding it up is using ZFS itself to do the backups with send/recv, thus avoiding the file operations altogether. But if I do that, I must use ZFS on the backup machine too.
I've yet to meet any service that can't recover smoothly from a kill -9 equivalent, any that did sure wouldn't be in my list of stuff I run anymore.
My thoughts precisely.
I don’t bother stopping services during backup, each service is contained to a single LVM volume, so snapshotting is exactly the same as yanking the plug. I haven’t had any issues yet, either with actual power failures or data restores.
And this implies you have tested such backups right?
Side Q, how long do those LVM snapshots take? How long does it take to merge them afterwards?
Yes, I have. I should probsbly test them again though, as it’s been a while, and Immich at least has had many potentially significant changes.
LVM snapshots are virtually instant, and there is no merge operation, so deleting the snapshot is also virtually instant. The way it works is by creating a new space where the difference from the main volume are written, so each time the application writes to the main volume the old block will be copied to the snapshot first. This does mean that disk performance will be somewhat lower than without snapshots, however I’ve not really noticed any practical implications. (I believe LVM typically creates my snapshots on a different physical disk from where the main volume lives though.)
You can my backup script here.
Wouldn't restoring from such a backup be equivalent to kill -9 or pulling the cable and restarting the service?
Disclaimer: Not familiar with Immich, but this is what I've experienced generally.
AFAIK, effectively yes. The only thing you might lose is anything in memory that hasn't been written to disk at the time the snapshot was taken (which is still effectively equivalent to
kill -9).At work, we use Veeam which is snapshot based, and database server restores (or spinning up a test DB based off of production) work just fine. That said, we still take scheduled dumps/backups of the database servers just to have known-good states to roll back to if ever the need arises.
Thanks for validating my reasoning. And yeah, this isn't Immich-specific, it would be valid for any process and its data.
I'd be cautious about the "kill -9" reasoning. It isn't necessarily equivalent to yanking power.
Contents of application memory lost, yes. Contents of unflushed OS buffers, no. Your db will be fsyncing (or moral equivalent thereof) if it's worth the name.
This is an aside; backing up from a volume snapshot is half a reasonable idea. (The other half is ensuring that you can restore from the backup, regularly, automatically, and the third half is ensuring that your automated validation can be relied on.)
Contents of application memory lost, yes. Contents of unflushed OS buffers, no. Your db will be fsyncing (or moral equivalent thereof) if it's worth the name.
Good point. I guess
kill -9is somewhat less catastrophic than a power-yank. If a service is written well enough to handle the latter it should be able to handle the former. Should, subject to very interesting bugs that can hide in the difference.This is an aside; backing up from a volume snapshot is half a reasonable idea. (The other half is ensuring that you can restore from the backup, regularly, automatically, and the third half is ensuring that your automated validation can be relied on.)
I'm currently thinking of setting up automatic restore of these backups on the off-site backup machine. That is the backups are transferred to the off-site machine, restored to the dirs of the services, then the services are started. This should cover the second half I think. Of course those services can't be used to store new data because they'll be regularly overwritten with every backup. In the event of a hard snafu where the main machine disappears, I could stop the auto restore on the off-site machine and start using the services from it, effectively making it the main machine. If this turns out to be reasonable and working, I might trash all of the file-based backup-and-transfer mechanisms and switch to ZFS send/recv. That should allow to shrink the data delta between main and off-site to minutes instead of hours or days. Does this make any sense?
I ran into a similar problem with snapshots of a forum and email server -- if there are scheduled emails when you take the snapshot they get sent out again if you create a new test server from the snapshot. And similarly for the forum.
I'm not sure what the solution is either. The emails are sent via an SMTP so it's not as simple as disabling email (ports, firewall, etc.) on the new test server.
Modern image snapshot backups stop the service for av instant, creates a local snapshot to backup while the service runs a Delta then you apply the Delta to the running image
When you say stopping the service for an instant you must mean pausing its execution or at least its IO. Actually stopping the service can't be guaranteed to take an instant. It can't be guaranteed to start in an instant. Worst of all, it can't even be guaranteed that it'll be able to start again. When I say stopping I mean
sysemctl stopordocker stoporpkilletc. In other words delivering an orderly, graceful kill signal and waiting for the process/es to stop execution.Correct, just pausing it on the underlying platform
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters LVM (Linux) Logical Volume Manager for filesystem mapping NFS Network File System, a Unix-based file-sharing protocol known for performance and efficiency SMTP Simple Mail Transfer Protocol ZFS Solaris/Linux filesystem focusing on data integrity
4 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.
[Thread #902 for this sub, first seen 1st Aug 2024, 21:25] [FAQ] [Full list] [Contact] [Source code]
Check "green blue" deployment strategy. This is done by many businesses, where an interrupted service might mean losing a sale, or a client forever... I tried it sometime witj Nginx but it was more pain than gain (for my personal use)
Good suggestion. I've done blue-green professionally with services that are built to have high availability and in cloud environments. If I were to actually setup some form of that, I'd probably use ZFS send/rcv to keep a backup server always 15 minutes behind and ready to go. I wouldn't deal with file-based backups that take an hour to just walk the dataset to just figure out what's new. 😅 Probably not happening for now.
If you're worried a out a database being corrupt, I'd recommend doing an actual backup dump of the database and not only backing up the raw disk files for it.
That should help provide some consistency. Of course it takes longer too if it's a big db
I dump the db too.
With that said if backing up the raw files of a db while the service is stopped can produce a bad backup, I think we have bigger problems. That's because restoring the raw files and starting the service is functionally equivalent to just starting the service with its existing raw files. If that could cause a problem then the service can't be trusted to be stopped and restarted either. Am I wrong?
I was talking about dumping the database as an alternative to backing up the raw database files without stopping the database first. Taking a filesystem-level snapshot of the raw database without stopping the database first also isn't guaranteed to be consistent. Most databases are fairly resilient now though and can recover themselves even if the raw files aren't completely consistent. Stopping the database first and then backing up the raw files should be fine.
The important thing is to test restoring :)