ploop snapshots and backups 10 June 2013 @ 11:40 pm
Kir Kolyshkin
OpenVZ ploop is a wonderful technology, and I want to share more of its wonderfulness with you. We have previously covered ploop in general and it's write tracker feature to help speed up container migration in particular. This time, I'd like to talk about snapshots and backups.

But let's start with yet another ploop feature -- it's expandable format. When you create a ploop container with say 10G of disk space, ploop image is just slightly larger than the size of actual container files. I just created centos-6-x86 container -- ploop image size is 747M, and inside CT df shows that 737M is used. Of course, for empty ploop image (with a fresh filesystem and zero files) the ratio will be worse. Now, when CT is writing data, ploop image is auto-growing up to accomodate the data size.

Now, these images can be layered, or stacked. Imagine having a single ploop image, consisting of blocks. We can add another image on top of the first one, so that new reads will fall through to the lower image (because the upper one is empty yet), while new writes will end up being written to the upper (top) image. Perhaps this image will save some more words here:


The new (top) image is now accumulating all the changes, while the old (bottom) one is in fact the read-only snapshot of the container filesystem. Such a snapshot is cheap and instant, because there is no need to copy a lot of data or do other costly operations. Of course, ploop is not limited to only two levels -- you can create much more (up to 255 if I remember correctly, which is way above any practical limit).

What can be done with such a snapshot? We can mount it and copy all the data to a backup (update: see Note that such backup is very fast, online and consistent. There's more to it though. A ploop snapshot, combined with a snapshot of a running container in memory (also known as a checkpoint) and a container configuration file(s), can serve as a real checkpoint to which you can roll back.

Consider the following scenario: you need to upgrade your web site backend inside your container. First, you do a container snapshot (I mean complete snapshot, including an in-memory image of a running container). Then you upgrade, and realize your web site is all messed up and broken. Horror story, is it? No. You just switch to before-upgrade snapshot and keep working as it. It's like moving back in time, and all this is done on a running container, i.e. you don't have to shut it down.

Finally, when you don't need a snapshot anymore, you can merge it back. Merging process is when changes from an upper level are written to a lower level (i.e. the one under it), then the upper level is removed. Such merging is of course not as instant as creating a snapshot, but it is online, so you can just keep working while ploop is working with merge.

All this can be performed from the command line using vzctl. For details, see vzctl(8) man page, section Snapshotting. Here's a quick howto:

Create a snapshot:
vzctl snapshot $CTID [--id $UUID] [--name name] [--description desc] [--skip-suspend] [--skip-config]

Mount a snapshot (say to copy the data to a backup):
vzctl snapshot-mount CTID --id uuid --target directory

Rollback to a snapshot:
vzctl snapshot-switch CTID --id uuid

Delete a snapshot (merging its data to a lower level image):
vzctl snapshot-delete CTID --id uuid
Permanent Link12 comments | Leave a comment
Post a new comment
LiveJournal: pingback_botlivejournal on June 11th, 2013 - 08:21 am
User knutov referenced to your post from ploop saying: [...] В общем, ploop - это такой LVM для опенвз - [...] pic#120725411lepus_hosting on June 11th, 2013 - 07:31 pm
ploop great solution
Andrew Vagin: pic#52636597shpagin on June 11th, 2013 - 08:17 pm
Кир, а вот я бы написал как сделать честный бекап. Делаем снапшот, маунтим его в сторонку в readonly и запускаем third party бекап решение, которое все сделает со всеми рюшечками. В итоге консистент бекап без lvm снапшота. Надо прямо команды написать, а то их даже я не знаю;)
Kir Kolyshkin: nepalk001 on June 12th, 2013 - 02:00 am
Я про это и написал. Но да, надо просто рецепт.
Kir Kolyshkin: nepalk001 on June 12th, 2013 - 02:37 am pic#120725411lepus_hosting on June 12th, 2013 - 01:14 pm
Мб стоит так же указать, что можно делать бекап одного файла -> root.hdd ?
Например, если в контейнере очень много мелких файлов -> будет очень долго архивировать. Да и разворачивать из бекапа потом тоже. А так один файл и готово.
Kir Kolyshkin: nepalk001 on June 13th, 2013 - 11:28 pm
Dmitry Kopytov on July 19th, 2013 - 01:36 pm
В этом примере команда cp копирует в т. ч. и дельту. Не вызовет ли проблем то что она может измениться в процессе копирования?
Kir Kolyshkin: nepalk001 on March 27th, 2014 - 12:47 am
Вероятно, в вопросе имеется в виду топ-дельта. По сути для бекапа она не нужна, но мы её не исключаем, потому что она маленькая, и чтобы не усложнять скрипт.
CoolCold: pic#23115555coolcold on June 13th, 2013 - 07:33 pm
"When you create a ploop container with day 10G of disk space" - mb say ?
Kir Kolyshkin: nepalk001 on June 13th, 2013 - 11:28 pm
fixed, thanks pic#120725411lepus_hosting on June 14th, 2013 - 08:36 pm
Кир, а что касается SSD? Есть какие-либо рекомендации?
ploop and ssd?
OpenVZ and ssd?