This is one of the more incredible possibilities. Let's say you have a busy server, with lots of things happening. For a useful backup, you need to shut down a large number of programs because otherwise you end up with inconsistencies.
The canonical example is moving a file from /tmp to /root, where /root was being backed up first. When /root was read, the file wasn't there yet. By the time /tmp was backed up, the file was gone.
Another story goes for saving databases or directories. We have no clue if a file is in any usable state unless we give the application time to do a clean shutdown.
Which is where another problem pops up. We shut down out applications, make our backup, and restart them again. This is all fine as long as the backup only takes a few minutes, but gets to be real painful if it takes hours, or if you're not even sure how long it takes.
LVM to the rescue.
With LVM we can make a snapshot picture of a Logical Volume which is instantaneous, and then mount that and make a backup of it.
Let's try this out:
# mount /dev/test/HOWTO /mnt
# echo > /mnt/a.test.file
# ls /mnt/
a.test.file lost+found
# ls -l /mnt/
total 13
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found
Ok, we now have something to work with. Let's make the snapshot:
# lvcreate --size 16m --snapshot --name snap /dev/test/HOWTO
lvcreate -- WARNING: all snapshots will be disabled if more than 16 MB are changed
lvcreate -- INFO: using default snapshot chunk size of 64 KB
lvcreate -- doing automatic backup of "test"
lvcreate -- logical volume "/dev/test/HOWTO" successfully created
More on the '--size' parameter later. Let's mount the snapshot:
# mount /dev/test/snap /snap
# ls /snap
total 13
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found
# rm /mnt/a.test.file
# ls /snap
total 13
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found
Amazing Mike!
Remember that we had to set the '--size' parameter? What really happens is that the 'snap' volume needs to have a copy of all blocks or 'chunks' as LVM calls them, which are changed in the original.
When we erased a.test.file, it's inode was removed. This caused 64 KB to be marked as 'dirty' - and a copy of the original data was written to the 'snap' volume. In this case we allocated 16MB for the snapshot, so if more than 16MB of "chunks" are modified, the snapshot will be deactivated.
To determine the correct size for a snapshot partition, you will have to guess based on usage patterns of the primary LV, and the amount of time the snapshot will be active. For example, an hour-long backup in the middle of the night when nobody is using the system may require very little space.
Please note that snapshots are not persistent. If you unload LVM or reboot, they are gone, and need to be recreated.