...надо делать бекапы с SSD на второй раид, тоесть локально.

rsync

Бекапирование

повбывав бы!

любишь ручную работу - рсинк. иначе бакула.

резервное копирование* =)

-Бекап субд postgres -Бекап виртуальной машины KVM

Для этих вещей нужен LVM snapshot или snapshot на уровне ФС (некоторые уже умеют, некоторые судорожно учатся). «на лету» такие вещи не не копируются.

lvm + rsnapshot например, очень легко настраивается

перед бекапом нужно все кеши postgresql на диск сбросить, и если в виртуалке крутится то, для чего потеря кеша сметрельна нужно ее засуспензить или выключить предварительно.

предварительно - всмысле перед созданием lvm снапшота

если в виртуалке крутится то, для чего потеря кеша сметрельна нужно ее засуспензить или выключить предварительно.

Если виртуалка нормальная, то ничего выключать не нужно. Просто перед созданием снимка lvm, нужно сделать снимок виртуальной машины. Только не состояние дисковой системы, а полное состояние виртуальной ОС. К примеру:

qemu-img snapshot -c filename

с какого ядра это работает и с кагого нормально работает?

мне вот что выдал: qemu-img: Could not create snapshot 'xp_1-snapshot': -95 (Operation not supported)

диск в raw, может дело в этом?

Да. Конечно. Такие вкусные плюшки только у qcow2. И эти плюшки значительно превосходят все минусы qcow2 по сравнению со всеми остальными вариантами. Главное только создать qcow2 в полном (распределенном) размере:

# qemu-img create -f qcow2 -o preallocation=metadata /tmp/test.img 8G
# ls -l /tmp/
-rw-r--r--. 1 root root 8591507456 Dec  2 16:55 /tmp/test.img
# ls -lash /tmp/
1.4M -rw-r--r--. 1 root root 8.1G Dec  2 16:55 /tmp/test.img
# fallocate -l 8591507456 /tmp/test.img
# ls -lash /tmp/
8.1G -rw-r--r--. 1 root root 8.1G Dec  2 16:55 /tmp/test.img

ЗЫ: у меня qcow2 на рабочем сервере и крутится там win2003x64

если не сложно, можно про минусы qcow2 ? ну кроме оверхеда в сравнении с lvm

[root@test /home/vm-images]# qemu-img snapshot -l xp_1.qcow2 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 xp_1.qcow2.snap 0 2012-08-30 19:16:53 00:00:00.000

Почему размер 0?

[root@test /home/vm-images]#  qemu-img snapshot -l xp_1.qcow2
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         xp_1.qcow2.snap        0 2012-08-30 19:16:53   00:00:00.000

Санитаров вызывали?

щас набегут санитары и ненавязчиво убедят, что лучше размещения в раздел LVM для продакшн серверов, ничего нет.

Размещение в разделе (в частности, в томе LVM), действительно, позволяет исключить оверхед, вызванный лишним слоем абстракции в виде файловой системы. Что мешает тебе создавать образ qcow2 внутри тома?

~# qemu-img create -f qcow2 /dev/mapper/vg00-vpbx1 20G

если не сложно, можно про минусы qcow2 ? ну кроме оверхеда в сравнении с lvm

1. Ну вот если взять плюс qcow2 заключенный в способности занимать ровно столько места, сколько реальных данных в него записано, то видно, что это одновременно является минусом из-за страшной фрагментации. Для этого я и распределял его на весь размер (см. выше).

2. Невозможность подмонтировать qcow2, как raw, mount-ом. Но это лечится переконвертацией qcow2 в raw, и если нужно: обратно.

3. Меньшая переносимость/совместимость формата.

4. Вроде бы, более худшая скорость при cache=none и writethru, чем у raw. Правда с writeback все замечательно.

VM SIZE 0

Какую версию qemu используете? У меня такой глюк был на старой версии 0.12.3. Причем интересно, что из самой консоли qemu, снимки создавались правильно, а qemu-img глючил. Сейчас использую 1.0 - никаких проблем. Снимки создаются корректно.

Что мешает тебе создавать образ qcow2 внутри тома?

Мешает то, что «/dev/mapper/vg00-vpbx1» блочное устройство.

Размещение в разделе (в частности, в томе LVM), действительно, позволяет исключить оверхед, вызванный лишним слоем абстракции в виде файловой системы.

Зато лишает возможности использовать кеширование этим «лишним слоем абстракции». А вот что выбирать решает администратор, в соответствии с потребностью. С одной стороны тормоза по чтению (в определенных случаях) и невозможность создания снимков состояния ОС, но получение максимальной надежности используя LVM. Хотя какая это надежность без нормальных снимков? С другой, ИМХО, самое главное достоинство - полноценные снимки. Тем более, что для qcow2 также можно запретить кеширование.

Мешает то, что «/dev/mapper/vg00-vpbx1» блочное устройство.

А мне почему-то не мешает) Всё работает, не тормозит, снапшоты снимаются. Склоняюсь к тому, что это оптимальный вариант.

Зато лишает возможности использовать кеширование этим «лишним слоем абстракции».

Кажется, оно нафиг не нужно. Оверхед при работе ВМ с диском совершенно не заметен.

Может я чего не понимаю, или мы говорим о разных вещах, но ткните меня носом в возможность создания qcow2 формата в блочном устройстве. Именно блочном, а не файле.

Всё работает, не тормозит, снапшоты снимаются.

Нисколько не сомневаюсь в том что все работает и не тормозит, но вот что за снапшоты снимаются? Состояния дисковой системы или состояния всей «работающей» ОС?

qemu-img snapshot -a ...

QEMU emulator version 1.1.0 (qemu-kvm-1.1.0+dfsg-3, Debian)

QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2) на другом тазике, с более старой версией, все также

Может я чего не понимаю, или мы говорим о разных вещах, но ткните меня носом в возможность создания qcow2 формата в блочном устройстве. Именно блочном, а не файле.

Так писал же)

~# lvcreate -L 20G -n vpbx1 vg00
~# qemu-img create -f qcow2 /dev/mapper/vg00-vpbx1 20G

~# virsh snapshot-revert --snapshotname=1321901427 vpbx1

Попробуйте:

sudo virsh snapshot-create-as vmname snapshotname
sudo qemu-img snapshot -l vmfilename

К сожалению, у меня нет сейчас возможности провести этот эксперимент (

Было бы интересно посмотреть выхлоп команды:

sudo qemu-img info /dev/mapper/vg00-vpbx1

ЗЫ: до сих пор не встречал информации о возможности создания qcow2 в блочном устройстве.

Было бы интересно посмотреть выхлоп команды

Да пожалуйста. Только оно показывает какую-то хрень.

~% sudo qemu-img info /dev/mapper/vg00-vpbx1       
image: /dev/mapper/vg00-vpbx1
file format: host_device
virtual size: 20G (21474836480 bytes)
disk size: 0

~% sudo qemu-img info -fqcow2 /dev/mapper/vg00-vpbx1
image: /dev/mapper/vg00-vpbx1
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 0
cluster_size: 65536

~% qemu-img -v
qemu-img version 0.9.1, Copyright (c) 2004-2008 Fabrice Bellard

~% rpm -qi kvm-qemu-img
Name        : kvm-qemu-img                 Relocations: (not relocatable)
Version     : 83                                Vendor: CentOS
Release     : 249.el5.centos.4              Build Date: Пнд 21 Май 2012 20:30:31
Install Date: Вск 10 Июн 2012 11:36:29      Build Host: builder10.centos.org
Group       : Development/Tools             Source RPM: kvm-83-249.el5.centos.4.src.rpm
Size        : 146542                           License: GPLv2
Signature   : DSA/SHA1, Пнд 21 Май 2012 20:42:54, Key ID a8a447dce8562897
URL         : http://kvm.sf.net
Summary     : Qemu disk image utility
Description :
This package contains qemu-img, the qemu command line tool for
manipulating disk images, built from the qemu source code included on
the KVM source.

qcow2 on LVM - что бы почитать?

Вот тебе ссылко на темко, где это всё обсуждалось в период становления. С тех пор ВР. Единственный косяк был однажды, когда после очень-очень некорректного завершения работы хостовой системы (с повисшими при выгрузке модулями и хард-ресетом) одна из виртуалок внезапно о_о откатилась к состоянию последнего снапшота. Вот смеху-то было... А в остальном полёт нормальный.

qcow2 on LVM - что бы почитать?

Почитал. Спасибо. Но все таки остаюсь на своей конфигурации. Дело в том, что я держу qcow2 файлы на LVM. И кроном сохраняю по ночам файлы целиком. Создаю снимок ВМ -> создаю снимок LVM -> монтирую снимок LVM -> копирую qcow2 файл по сети -> размонтирую снимки и удаляю. С LVM разделом это будет труднее и главное, сохраненный qcow2 файл взлетит на практически любом компе, а с LVM разделом придется дополнительно возиться с инициализацией подходящей структуры разделов.

И еще одно преимущество. qcow2 файлы я сохраняю инкрементально каждый день недели и далее каждый выходной месяца. И буде возникнет необходимость, я могу на том же файлархивном сервере (весьма слабеньком, но с большим зеркалом) подмонтировать qcow2 файл за нужную дату и вынуть из него удаленный/измененный файл, папку и т.д. НЕ ЗАПУСКАЯ ВМ! Конечно это можно сделать и с dd копией LVM раздела, но значительно сложнее.

bacula

тогда создание снапшота происходит с предварительным суспендром машины, а это не очень интересно

хотя по другому и невозможно наверно

тогда создание снапшота происходит с предварительным суспендром машины

Что Вы подразумеваете под «предварительным суспендром»? Некоторое заикание на одну-несколько секунд? Так по другому и не бывает. Если вы дадите команду «savevm name» в консоле qemu, то будет тоже самое. Это и есть создание снимка, а длительность заикания зависит от объема ОП, ее загрузки и т.п.

просто когда Вы написали - «Если виртуалка нормальная, то ничего выключать не нужно» , подумал что можно прям совсем онлайн бекап, а так можно и без снапшотов обойтись, перед созданием lvm снапшота суспенд делать.

Что Вы подразумеваете под суспенд? Это:

virsh suspend domain-id
или
qemu-monitor: stop

Так это просто пауза гостя, без сохранения состояния ВМ на диск. Или Вы говорите о чем-то другом?

suspend %guestname% в virsh консоли

man virsh:

list [--inactive | --all] [--managed-save]       Prints information about existing domains.  If no options are specified it prints out information about running domains.

STATES

paused       The domain has been paused, usually occurring through the administrator running virsh suspend.  When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the hypervisor.

--snip--

suspend domain-id     Suspend a running domain. It is kept in memory but won't be scheduled anymore.

где еще можно ознакомится с МАНом как не на лоре) глянул в /etc/init.d/libvirt-guests там managedsave используется, с ним походу можно.

Видимо это какой-то libvirt-овский велосипед. Не могу сказать точно. По крайней мере, в QEMU Monitor есть единственная команда для сохранения состояния виртуальной машины: 'savevm'.

Мешает то, что «/dev/mapper/vg00-vpbx1» блочное устройство.

чем это мешает?

Хотя какая это надежность без нормальных снимков?

qcow2 snapshots можно делать и на LVM

Да. Спасибо. Я уже разобрался. Просто все хауту, которые мне попадались, в явном виде эту возможность не показывали. И только после вдумчивого прочтения первого параграфа все прояснилось.

просто надо отедлять мух от котлет, LVM и файлы это одно, a raw/qcow2 - совсем другое, и комбинировать их можно как угодно