A backup run takes time. During a backup run the live data may change. This can mean that the snapshot of the live data may not be internally consistent.

For example, suppose you're writing an e-mail when the backup starts automatically. If the timing goes wrong in exactly the right way, the backup might capture both the draft e-mail you were writing when the backup started, and the sent e-mail, when you finished the draft and sent the mail before the backup ended.

Or, worse, the backup might miss both the draft and the sent e-mail. The next backup run will, certainly, get the sent e-mail, but what if you have a disaster before that happens?

Internal consistency of data can be quite difficult to achive. Some programs, such as MySQL, don't do a good job of keeping the data consistent on-disk, making it difficult for the backup program to get a proper setup. (In that case, a standard trick is to "dump" or "export" the data in a consistent form, and back that up instead.)

In an ideal situation, when the backup starts, the system would have a way to tell all running programs to store all their state on disk in a recoverable manner (save all open documents, dump data base content, etc), and once that is done, the backup program creates a snapshot of the filesystem. Unfortunately, I don't know of any operating system that can request consistent state from running applications.

Snapshotting, however, is easy-peasy. It can be achieved by the filesystem (e.g., btrfs), or using LVM. Doing the snapshots requires root privileges, but that can probably be arranged. However, snapshotting like this, without getting all programs to commit their state to disk first, is not a guarantee of consistency.

A thorough way to be consistent is to shut down the computer, and then reboot it into a special backup mode (similar to single-user mode), where no services or applications are running. However, this is, for most people, much too heavyweight a procedure to be worth it.

Does consistency really matter? It matters a lot when the live data is being changed actively and consistency of the data is critical. For example, a bank's database of the amount of money in each account is quite critical: if data is not backed up consistently, money can be lost or created spontaneously, and that's probably a bad thing.

Most people, however, don't need to worry a lot, and merely need to be aware of the issue, and perhaps mitigate it by backing up when the computer is mostly idle, and run backups often enough.

Oh dear. This blog post contains too few jokes. I seem to have run out of jokes to make, so that will conclude this series of blog posts. I hope it was useful to some.

You write: "Unfortunately, I don't know of any operating system that can request consistent state from running applications."

Microsoft Windows Server, since 2003 has had a system called "Volume Shadow Copy Service" that does just that. I quote http://en.wikipedia.org/wiki/Quiesce:

"For an application to be quiesced during the shadow copy process, it must register itself as a writer and it is responsible for putting itself into a quiescent mode upon notification"

More information here: http://technet.microsoft.com/en-us/library/cc738819%28v=ws.10%29.aspx

Many backup solutions for Windows make use of this service, and many applications support "quiescing" via VSS. See mentioned Wikipedia page for a list.

Without quescing applications, the best you can do is create backups of "crash-consistent" snapshots, i.e. backups with the same kind of consistency you would have in a system that just crashed due to a power failure or something like that. If you do backups this way, backing up transaction logs, file system journals and stuff like that is essential, and even then, there is no guarantee that your backup will be fully restoreable.

I think internal consistency is more important than you say, especially when backing up databases or other large binary objects. At least, people should be very aware of the possible implications of doing only crash-consistent backups.

Comment by Martijn Tue Jul 2 10:04:54 2013

http://en.wikipedia.org/wiki/Quiesce http://blogs.technet.com/b/enterprise_admin/archive/2009/11/18/the-wonder-of-volume-shadow-copy-and-hyper-v.aspx

Comment by Mark Tue Jul 2 11:28:26 2013

Yes, your post was very helpful in reasoning and meditate about the correct way to do backups. It helps me to focus better on what was my own first aims and the possible flaws of my current set up.

Anyway something like quiesce could be already archive on free system in a easy way dealing with snapshot (eg. LVM) and taking care of breakable application (eg. using dump for myslq/postgresql): http://unix.stackexchange.com/questions/48653/does-quiesce-exist-for-linux At least it has always worked on my mochines...

Comment by Risca Tue Jul 2 13:15:08 2013
Your series really stroke a chord with me: I was on the verge of starting doing backups already (hey, better late than never!) and your posts helped me to see a lot of aspects to the process that I didn't think of before. And of course I'll use Obnam :) So thank you for both the series and the program.
Comment by Alexander Batischev Tue Jul 2 16:22:52 2013

Assuming that the filesystem snapshot works it's not worth worrying about the databases and applications.

Imagine that an application keeps inconsistant data on disk and doesn't work after a restore.

Would that application work after a crash? No.

And systems crash much more often than they need to be restored from backup.

Comment by JohnHughesChampigny Thu Jul 4 22:33:20 2013