А теперь к забавной теме образов виртуальных машин!
Мой компьютер синий экран на днях. Так что я стал довольно параноиком. Это второй раз за месяц, это случилось. Мне нужно было убедиться, что моя стратегия резервного копирования была надежной. Самое важное, что я хочу сделать резервную копию — это мой образ Ubuntu VirtualBox. Здесь, на работе, мы используем CrashPlan, который, кажется, выполняет достаточно приличную работу, автоматически копируя каталоги, о которых я говорю. Однако глупый я просто указывал CrashPlan на каталог с образами моей виртуальной машины и надеялся на лучшее. Это, конечно, проблематично, поскольку CrashPlan, скорее всего, выполняет резервное копирование, пока я активно работаю на своей виртуальной машине. Как я могу гарантировать, что изображение находится в каком-либо согласованном состоянии?
Резервное копирование с помощью системы управления версиями
Я попробовал всевозможные схемы для создания резервной копии своего образа виртуальной коробки в автоматическом режиме. Я действительно хотел какой-то подход на основе diff для резервного копирования большого файла. Одна мысль, которая у меня возникла, заключалась в том, что перед запуском виртуальной машины в пакетном файле или скрипте я передал ее в систему управления версиями. Затем я бы указал CrashPlan на связанный репозиторий, который будет копироваться в фоновом режиме. Я не рекомендую это. У Git оказывается разумный максимальный предел файла , который был довольно большим предупреждением «эй, идиот… что ты делаешь». Я нашел и попробовал Кабанасистема управления версиями, которая пытается работать хорошо для двоичных файлов. К сожалению, даже его способность рассеивания в этой ситуации отсутствовала. После 2 коммитов файла .vdi размером 20 ГБ хранилище выросло до 40 ГБ +. Это решение не было очень экономичным. Более того, создание такого большого файла утомительно медленно. Каждый раз, когда я запускал свою виртуальную машину, мне приходилось ждать этого скучного 5-10-минутного процесса.
Резервное копирование с использованием снимков VirtualBox
Оказывается, каноническое решение включает в себя функцию VirtualBox, известную как моментальные снимки, о которых раньше я ничего не знал.
С точки зрения пользователей снимок является точкой восстановления. Если я создаю снимок, я могу вернуться к этому моменту времени. Самое приятное, что я могу сделать снимок системы даже во время ее работы. В простейшем случае использования у вас есть линейная прогрессия во времени различных снимков. Вы можете восстановить вашу виртуальную машину до любого снимка в истории. Вы также можете делать сумасшедшие вещи, например возвращаться к снимку и создавать ветку из этого снимка — перемещая вашу виртуальную машину в нескольких экспериментальных направлениях из одной точки восстановления.
То, как на самом деле работают снимки, делает их чрезвычайно мощными для резервного копирования. Снимок оказывается той системой, которую я искал. Когда вы делаете снимок виртуальной машины, в «нормальном» режиме по умолчанию связанный родительский элемент (или образ виртуальной машины, или другой снимок) замораживается и больше не записывается. Вместо этого все записи идут в файл, связанный с новым снимком. Этот файл по сути является своего рода журналом фиксации для базовой виртуальной файловой системы всего, что произошло после моментального снимка. Это разные вещи, которые изменились с момента создания снимка. Восстановление к точке моментального снимка так же просто, как удаление файла снимка — журнал фиксации — и размораживание предка снимка.
Удаление снимка не удаляет все изменения в этом журнале фиксации. Вместо этого он складывает этот снимок в своего предка (обратно в vdi или другой файл сравнения). Это на самом деле совершение различий.
Что приводит меня к пониманию того, почему это может работать как стратегия резервного копирования.
#!/bin/bash
VBOXMANAGE="/usr/bin/VBoxManage -q"
if [ $# != 1 ]
then
echo "Usage: $0 VBoxName"
exit
fi
echo "Renaming old snapshot..."
$VBOXMANAGE snapshot "$1" edit previous --name deleteme
echo "Renaming current snapshot..."
$VBOXMANAGE snapshot "$1" edit current --name previous
echo "Taking new snapshot..."
$VBOXMANAGE snapshot "$1" take current
echo "Deleting old snapshot..."
$VBOXMANAGE snapshot "$1" delete deleteme
Вы можете сделать резервную копию работающей виртуальной машины VirtualBox, поддерживая каскад снимков. Один снимок, известный как «текущий», является самым последним снимком. Восстановление к нему восстанавливает до последней резервной копии. Файл diff, связанный с ним (содержит все, что произошло после Снимка), отражает все неподкрепленные изменения и является тем местом, где VirtualBox активно хранит записи гостевой ОС. Этот diff является своего рода «журналом фиксации» всех изменений, которые происходят на виртуальном диске. «Предыдущий» снимок — это точка восстановления до текущей. В этом сценарии предыдущий журнал фиксации является старым током. Журнал фиксации / разница, связанный с «предыдущими», отражает изменения между предыдущими / текущими снимками. Наконец, этот скрипт также имеет «deleteMe» — старый предыдущий. При каждом запуске deleteMe,складывается обратно в основной файл vdi, сообщая VBoxManage удалить снимок (удаление снимка не удаляет связанные данные, оно просто складывает данные и забывает точку восстановления).
Эта стратегия позволяет нам сохранить 2 точки восстановления (в случае, если случайное резервное копирование создает резервную копию нестабильного образа). Это отличная стратегия, но …
Снимки — протектор осторожно
К сожалению, лично для меня живые снимки VirtualBox не были ужасно надежной стратегией резервного копирования. Я, к сожалению, видел несколько неудачных снимков. Или, что еще хуже, произошел сбой VirtualBox во время создания снимка. К счастью, я не потерял много данных, так как я старательно отправлял свой код на github. Когда снимок не удался, мне пришлось редактировать файл vbox.xml моей виртуальной машины. Файл, в котором четко указано «НЕ РЕДАКТИРОВАТЬ» вверху. Легко впасть в затишье, думая, что это похоже на что-то, что должно либо преуспеть, либо потерпеть неудачу атомарно, как переход в систему управления версиями. Это не мой опыт, что это так.
Вот галерея ужасов некоторых ошибок, которые я видел. Во-первых, «Различающееся изображение снимка не может быть найдено», в котором файл снимка каким-то образом теряется.
Я также сталкивался с этой ошибкой — «Жесткий диск XXX не может быть напрямую подключен к виртуальной машине, потому что он имеет 1 разностный дочерний жесткий диск». У меня были ошибки при создании снимков, в том числе зависание процесса снимка с работающей виртуальной машиной. К сожалению, я не могу сказать, что доверяю живым снимкам прямо сейчас.
Я вернулся к более простой, нежизнеспособной стратегии резервного копирования, которая делает снимки только непосредственно перед запуском моей виртуальной машины и не снимает моментальный снимок во время работы VirtualBox.exe (с просьбой закрыть VirtualBox перед продолжением). Это комбинация приведенного выше сценария, переработанного в Python для Windows, и этого рецепта Python ActiveState . Я заменил значок VirtualBox, закрепленный на панели задач, на командный файл, который запускает мой скрипт, и использую значок VirtualBox по умолчанию на панели задач.
У меня также только один снимок, который сейчас работает — «текущий». Перед запуском VirtualBox текущее уплотняется в основное изображение vdi посредством удаления снимка. Затем я делаю новый «текущий» снимок, который использует VirtualBox. Для меня это пока лучшее решение. У меня есть одно разностное изображение, активное одновременно. Основной vdi обновляется непосредственно перед запуском виртуальной машины. Поэтому, когда аварийный план создает резервную копию этой папки, он должен создавать резервные копии стабильных vdi, которые не постоянно меняются и становятся нестабильными. Это ** кажется ** лучшим решением для меня для поддержания надежной стратегии резервного копирования без каких-либо странных ошибок, которые приводят к сбою моей работающей виртуальной машины.
В любом случае, мне было бы интересно узнать о вашем опыте резервного копирования виртуальных машин!