Как сделать полный бэкап системы (Linux) rsync или tar?

Доброго времени коллеги!
Нужно автоматизировать бэкап виртуальных машин (Linux) под управлением qemu/kvm.
Нужно полностью забекапить "/".
Процесс монтирования qcow машины и прочие подготовительные шаги уже сделаны и тут нет ни каких сложностей.
/ (остановленной) виртуальной машины смонтирован в /mnt
Попробовал через rsync
rsync -av /mnt /srv/vm_name
Восстанавливал так же
rsync -av /srv/vm_name /mnt
Система падает на initramfs. Наверняка что-то с правами доступа к файлам.
Попробовал через tar
cd /mnt
tar -cvzpf /srv/vm_name.tar.gz .

Восстановление:
cd /mnt
tar --same-owner -xvpf /srv/vm_name.tar.gz

Уже лучше!
VM загружается...
Но! Не дает войти по логину паролю. Ни через консоль, ни по ssh.
При входе через консоль, что-то пытается сказать, но так быстро, что не успеваю прочесть.
При попытке входа по ssh, сразу после ввода логина и пароля, рвет соединение.
Дистрибутив на VM Fedora35.
Вроде, Debian, после восстановления работает нормально. Не проверял.
Сразу хочу уточнить: dd, veem, acronis & etc не предлогать!
cp vm_name.qcow2 vm_name.qcow.bak Так же не интересен.
Наиболее интересен вариант с rsync. На худой конец, tar.
Ну и факультативно: можно ли схожим образом бэкапить Windows (7,8,10....)?

UPD /boot в отдельном разделе диска
  • Вопрос задан
  • 1284 просмотра
Решения вопроса 1
@HighMan Автор вопроса
Давно заданный вопрос так и остался без решения. Однако, сейчас встала задача и данный вопрос снова стал актуальным.
Занялся чуть более вдумчиво и...
Ставим Debian 11 на виртуалку. Монтируем qcow2 через nbd, потом / монтируем в /mnt
cd /mnt
tar -cvpfz /srv/debian.tar.gz .

Ой. Забыл совет: Debian по стандартной разбивке не выделяет отдельный раздел под /boot, потому лучше бить вручную. /boot мы трогать не будем.
Создался архив. Крысота!
rm -fr /mnt/*
ls /mnt

Ой! Пусто! Что же я наделал????
Но есть же архив!
cd /mnt
tar -xvzpf /srv/debian.tar.gz
sync

Отмонтируемся. Запускаем виртуалку. Зашибись! Система работает.
Но мы не ищем простых путей. Хочется иметь универсальный способ. Fedora у меня в прошлый раз не заработала. Точнее, заработала, но не дала авторизоваться. После ввода пароля мгновенное нечитаемое сообщение и снова приглашение авторизации.
На виртуалку ставим Centos 8 Stream. С Федориным горем находятся в ближайшем родстве.
Повторяем все издевательства как с Debian. Система запускается, но ровно с тем же результатом. После ввода пароля на мгновение нечитаемое сообщение и снова запрос авторизации.
Сука-а-а!
Заново гасим, монтируем лезем смотреть логи.
Мать! Хрен поймёшь! Вроде все норм, но почему-то всплывают невнятные сообщения от selinux. Тааак! Я же не отключал этот глюк! Фактически, доставил пару пакетов на свежую систему и больше ни чего не делал.
Отрубаем selinux. Размонтируемся. Загружаемся. Авторизуемся.
Все работает! Что-то не понравилось selinux, но с ним нет ни какого желания разбираться. Все равно он у меня всегда живёт в DISABLED режиме.
Если кто-то знает, как договориться с selinux - напишите! Я с ним разбираться не хочу, но для расширения кругозора, не помешает.
В общем, можно прекрасно быкапить систему в оффлайне с помощью tar. И не только быкапить, но и восстанавливать!))
Многие удивятся: нахрена тебе этот геморрой, если есть снапшоты у вартуалки, да и LVM можно снапшотить... Для чего?
Да потому что не снапшот!
Я снапшотами даже на виртуалках не пользуюсь.
Слишком велики накладные расходы!
А такой способ бэкапа ни к чему не обязывает. Нужно лишь место для хранения архивов.
Но,на самом деле, вернуться к этой проблеме меня заставила другая необходимость.
Нужно заливать прошивки на устройства. На много тысяч устройств.
Можно, конечно, ставить систему и дальше на нее заливать нужный софт. Ansible в помощь.
Но такой подход не плох, когда нужно залить один девайс. Ну, десяток!
А если больше, то это совсем беда.
А так подготавливаем один девайс. Тестим.
Если все зашибись, то с помощью dd снимаем /boot раздел. Дальше / архируем tar.
Осталось лишь автоматизировать процес, но это ерунда! Не шибко большой bash скрипт сумеет разбить диск, залить /boot, распаковать архив в / раздел.
Быстро и следить не нужно.
Осталось лишь разобраться с "анонимизацией" эталонной системы.
Буду очень благодарен, если кто-то подскажет, что и как убивать в эталонной системе, что бы ее можно было клонировать на тысячи однотипных устройств.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
meDveD_spb
@meDveD_spb
откуда вообще могли возникнуть мысли, что это могут быть подходящие варианты?
это не так.

под управлением qemu/kvm.

устанавливаем PVE, потом PBS. всё.
Ответ написан
Комментировать
@MaxKozlov
Не знаю зачем, но можете посмотреть rear
https://relax-and-recover.org/
там и tar и rsync и всё что хочешь
С зералами на btrfs только не дружит, а так - идеальный велосипед
Ответ написан
Комментировать
@voleg4u
http://www.voleg.info/
Есть также снапшоты, на урожне QEMU либо libvirt. Почитать можно ЗДЕСЬ
Ответ написан
@rPman
Итак, первое и главное - способ, формат и время создания резервной копии должна определяться теми методами, которыми этот бакап будет восстанавливаться.

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

Второе, способов создания резервной копии операционной системы - огромное количество, каждый из них отличается удобством как создания копии так ее восстановления, и плюсы не всегда сочетаются с минусами.

Резервная копия на уровне файлов это rsync или tar, позволяет управлять что копировать а что пропускать на уровне файлов, но самая медленная из возможных. Помним, если в файлы идет запись то нормально резервную копию можно делать только из снапшота или выключив машину. Для восстановления такой метод требует наибольшее количество телодвижений, но как один из шагов - вполне допускается

Резервная копия на уровне блочных устройств:
* как уже сказал, если виртуальная машина использует файлы для хранения образов дисков - можно просто их копировать (отключив или приостановив ее само собой, либо используя снапшоты гипервизора)
* можно копировать диски изнутри из гостевой системы ее средствами, в этом случае можно использовать ее технологии снапшотов
Например в linux при использовании btrfs можно моментально создать снапшот и получить в виде файла (потоком) разницу между этим снапшотом и предыдущим, хранить их а потом эти инкрементальные копии применить последовательно для другой стартовой копии диска (так можно делать начиная с пустого диска)

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы