Lvm Snapshot Backup

1. Create a snapshot:

Lvcreate -- size 100 M -- snapshot -- name mdb-snap01/dev/vg0/mongodb

Because it is an incremental snapshot, 100M is the size of diff.

2. After the snapshot volume is mounted, It is copied. The write-time orientation (COW) is used)

I guess: After a snapshot is generated, the modification of the block corresponding to the original volume should be a new block, and the old block will not be deleted because of snapshot reference.

3. snapshot Archiving

Umount during archiving, then dd, gzip:

Umount/dev/vg0/mdb-snap01 dd if =/dev/vg0/mdb-snap01 | gzip> mdb-snap01.gz

When using mongo or mysql, you only need a read lock and flush the corresponding changes to create a real-time snapshot to release the read lock. The backup will be completed in a short time, with little impact on online services.

However, I also saw a question about performance on Weibo:

Terry Wang: A colleague said he tried to avoid using LVM because he did some tests and concluded that LVM2 has nearly 40% additional performance overhead compared to the same file system on Block devices. This is far from what I know: performance loss is negligible as it is flexible. After research, we found that there was a real problem. The existence of snapshots had a huge impact on the I/O performance of the logical volume (related to Copy on Write). The larger the chunksize, the better.

To avoid performance degradation, snapshot volumes must be archived and released immediately.

The Snapshot images in vmware and kvm use similar technologies.

You have time to do it manually. Do you need to know when to stop the snapshot? When is lvcreate or umount?