LVM snapshot vs backup

fanoflq · 04-26-2016, 02:57 AM

I read this article here on snapshot vs backup:
1) https://en.wikipedia.org/wiki/Snapsh...ter_storage%29

And I also read this:
2) http://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html

In 1), the writer wrote snapshot is much faster than backup.
Assume we are backing up to another area of same disk and assume
our snapshot located on same disk.

The author wrote:

Quote:

One approach to safely backing up live data is to temporarily disable write access to data during the backup, either by stopping the accessing applications or by using the locking API provided by the operating system to enforce exclusive read access

(OK, I get that.)

and this:

Quote:

To avoid downtime, high-availability systems may instead perform the backup on a snapshot—a read-only copy of the data set frozen at a point in time—and allow applications to continue writing to their data. Most snapshot implementations are efficient and can create snapshots in O(1). In other words, the time and I/O needed to create the snapshot does not increase with the size of the data set; by contrast, the time and I/O required for a direct backup is proportional to the size of the data set.

I fail to see why snapshot is faster since you still have to copy entire data set from one area to another area. You still have to prevent data corruption (as in stop application from writing to Logical Volume) while doing snapshot, just like backup.

What did I missed?

May be this can help me clear up my misunderstanding.
Assuming we are not doing delta snapshots, why snapshot time does not increase with data size?

Thank you.

syg00 · 04-26-2016, 03:28 AM

Quote:

Originally Posted by fanoflq

What did I missed?

copy-on-write.
The snaps take (effectively) no space - and no I/O. When data changes on the source filesystem, the unmodified block is copied to the snap. Hence snaps increase in size over time as more (original) data is modified. The blocks are only copied to the snap when they are written to (copy-on-write). Much more efficient.

However, they aren't backups. But you can use them to take backups from (a point-in-time backup) then delete the snap without affecting the original data or the application(s) using the data.

fanoflq · 04-26-2016, 03:53 AM

Thank you.

Quote:

However, they aren't backups. But you can use them to take backups from (a point-in-time backup) then delete the snap without affecting the original data or the application(s) using the data.

Here is how I interpret your response:
The snap is unmodified data from source.
A snap is a clone of the original source if all blocks in source were modified at least once.
If there is no modification to source, snap is empty.

How does backups from (a point-in-time backup) works?
If snap is only partial image of source when source has only modified its data partially, how does a point-in-time backup works?

To backup in above scenario, it looks like we still have to pull data from source and from snap. And this can prevent other application from writes. Thus slowing down snapshot-based backup.

Then high-availability systems is no longer valid with LVM systems.
Correct?

Thank you.