?

Log in

Previous Entry | Next Entry

ploop snapshots and backups

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:

ploop-stacked-images

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 openvz.org/Ploop/backup). 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

Comments

( 12 comments — Leave a comment )
livejournal
Jun. 11th, 2013 08:21 am (UTC)
ploop
User knutov referenced to your post from ploop saying: [...] В общем, ploop - это такой LVM для опенвз - http://openvz.livejournal.com/44508.html [...]
lepus_hosting
Jun. 11th, 2013 07:31 pm (UTC)
ploop great solution
shpagin
Jun. 11th, 2013 08:17 pm (UTC)
Кир, а вот я бы написал как сделать честный бекап. Делаем снапшот, маунтим его в сторонку в readonly и запускаем third party бекап решение, которое все сделает со всеми рюшечками. В итоге консистент бекап без lvm снапшота. Надо прямо команды написать, а то их даже я не знаю;)
k001
Jun. 12th, 2013 02:00 am (UTC)
Я про это и написал. Но да, надо просто рецепт.
k001
Jun. 12th, 2013 02:37 am (UTC)
lepus_hosting
Jun. 12th, 2013 01:14 pm (UTC)
Мб стоит так же указать, что можно делать бекап одного файла -> root.hdd ?
Например, если в контейнере очень много мелких файлов -> будет очень долго архивировать. Да и разворачивать из бекапа потом тоже. А так один файл и готово.
k001
Jun. 13th, 2013 11:28 pm (UTC)
Dmitry Kopytov
Jul. 19th, 2013 01:36 pm (UTC)
В этом примере команда cp копирует в т. ч. и дельту. Не вызовет ли проблем то что она может измениться в процессе копирования?
k001
Mar. 27th, 2014 12:47 am (UTC)
Вероятно, в вопросе имеется в виду топ-дельта. По сути для бекапа она не нужна, но мы её не исключаем, потому что она маленькая, и чтобы не усложнять скрипт.
coolcold
Jun. 13th, 2013 07:33 pm (UTC)
"When you create a ploop container with day 10G of disk space" - mb say ?
k001
Jun. 13th, 2013 11:28 pm (UTC)
fixed, thanks
lepus_hosting
Jun. 14th, 2013 08:36 pm (UTC)
Кир, а что касается SSD? Есть какие-либо рекомендации?
ploop and ssd?
OpenVZ and ssd?
( 12 comments — Leave a comment )

Latest Month

July 2015
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
Powered by LiveJournal.com
Designed by Tiffany Chow