system backup через dd

«Если делать system backup через dd во время работы самой системы…»

Да

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

один из выходов из ситуации - работа через снимок/снапшот системы в CoW фс (zfs btrfs) или снимок через lvm.

Спасибо, понятно. Непонятно, почему поиск не подкинул эту ссылку, наверное из-за лишнего слова «system»

один из выходов из ситуации - работа через снимок/снапшот системы в CoW фс (zfs btrfs) или снимок через lvm.

Перенос ОС с одного внешнего диска на другой внешний (комментарий)

базы данных бекапить вообще внутренними бы средствами надоть.

Это то понятно, но прочитавшим твой коммент может ошибочно показаться, что «снимки всё бэкапят консистентно» Я для информации решил добавить :)

Вообще чем и как

Прощу прощения за неактуальную информацию, сами мы не местные, но хотя бы ясно почему не дд и куда гуглить.
https://rus-linux.net/MyLDP/admin/backing-up-unix_ru.html

ну заголовок про system backup :)
хотя не уверен, что %тс% разделяет систему и данные…

если б заранее подготовил систему по типу «разделяй и властвуй» то таких вопросов бы не возникало.

system backup через dd во время работы самой системы

Можно делать (я много раз делал). Система не меняется, логи не самое важное при срочном восстановлении. fsck после восстановления почекает файловую систему.

В общем и целом, восстановление системы через dd – это как неожиданно откл. и вкл. электричество (нажать reset). Учитывая что ты админ и можешь максимально ограничить активность системы во время бэкапа, получается что через dd это «легче» чем внезапный рестарт (для системы)

Бэкап данных приложений и/или БД, это другая песня.

Не консистентно а атомарно :-) часто путают люди

Тебе посто везло. Собрать неконстстентный статус в таком режиме легче легкого. Скорей даже как раз он такой и соберется чем наоборот

переводишь фс в ro и бэкапишь

неконстстентный статус

это о чем? система (gnu/linux) по-сути статична (запись логов не в счет). Что там неконсистентного будет, да еще и такого чтобы fsck автоматом не починил?

Ну какие могут быть проблемы?

Собственно, в мире идиотов, какие вообще могут проблемы? Одно волшебство и магия…

Создание архива системы Linux c помощью cоздание Squashfs образа

(полноценная файловая система в одном файле, которую можно очень быстро примонтировать и быстро извлечь нужные файлы)

sudo mksquashfs / /root-backup.sqsh -e root-backup.sqsh home media dev run mnt proc sys tmp –создание Squashfs образа

sudo mount /root-backup.sqsh /mnt/ -t squashfs -o loop –примонтировать Squashfs образ

Я в упор не понимаю, какой смысл делать резервную копию с помощью dd?

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

Другая ситуация, когда надо просто скопировать диск как есть на другой и опять таки хочется это делать самым простым, универсальным, пусть и очень долгим способом.

Именно резервную копию. Ведь ее не делают единожды. Значит рядом лежит предыдущая, от которой можно скопировать только дельту. Резервную копию невозможно проверить и значит она должна делаться максимально надежно, чтобы уж точно помочь в случае аварии. И ведь есть варианты! Есть снепшоты, есть rsync. Быстро, умно и надежно.

dd

используй btrfs или zfs делай снапшёт его бекапь, но по мне это не гуд я юзаю ext4 бекап базы данных средствами бд, и для всего остального перевод fs в режим только чтения, бекаплю-копирую, для виртуальных машин есть свои средства создания снепшотов на живой машине.

Резервирование основных системных файлов.

можно банально создать TAR архив, сжатый ZIP или если нужно быстрее то не сжатый

sudo tar czf /backup.tar.gz –exclude=/backup.tar.gz –exclude=/home –exclude=/media –exclude=/dev –exclude=/mnt –exclude=/proc –exclude=/sys –exclude=/tmp /

c - означает, что нужно создать архив (Create), z - сжатие Gzip. f - указываем файл для сохранение архива. С помощью –exclude исключаем из архива сам файл архива, домашний каталог и директории с виртуальными файловыми системами. В самом конце указываем папку, с которой стоит начать сбор данных - /.

Для восстановления системы нужно загрузиться с LiveCD, примонтировать корневой каталог в /mnt, подключить носитель с резервной копией и выполнить команду для распаковки:

sudo tar xf /run/media/имя_носителя/backup.tar.gz -C /mnt

Не восстанавливается только загрузчик, восстановить Grub или Lilo нужно отдельно если он был поврежден.

Или если архив не нужен то просто можно воспользоваться утилитой RSYNC, но нужно учесть что при переносе данных на файловую систему отличную от EXT потеряются права на файлы

Создание архива системы Linux c помощью RSYNC

rsync -aAXv –exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /папка/назначения

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

–exclude исключает из копии виртуальные файловые системы.

Да. Через dd определённо БУДУТ косяки.

На живую бэкап делается с помощью tar, опции можно посмотреть в инструкции stage4 Генту. Естественно не надо делать этого прямо в время установки/удаления/обновления пакетов, а так 3 или 4 раза разворачивал на практике - 0 проблем. С хомяком тоже можно.

Данным как раз почти ничего не грозит, а вот метаданные ФС 100% будут повреждены. Есть шанс что при восстановлении ФС решит чего то потереть от греха подальше.

...ну или так.

А ваша версия rsync само собой исключает из процесса синхронизации вот эту, указанную вами не «виртуальную файловую систему» /папка/назначения ?

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

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

Разница с отключением принципиальная.

При отключении запись прекращается сразу. Что было записано до — останется записано. Что не было — то не будет.

При работе dd система продолжает работать. Если dd работает сутки, то в начале дампа будут данные, записанные вчера в начало диска, в конце — сегодня в конец. Это абсолютно на 200% неконсистентная копия. К такой ситуации ни одна ФС не готова.

Для имитации отключения есть lvm snapshots и в крайнем случае fsfreeze.

Какие сутки? Система на сервере в 8-32гб не больше. Пишутся только логи, при желании запись логов можно остановить. Да и /var должен быть отделён от /

А ваша версия rsync само собой исключает из процесса синхронизации вот эту, указанную вами не «виртуальную файловую систему» /папка/назначения ?

ну не то чтобы «само собой», но –exclude=/dir никто не отменял

И если резервируемое случайно состоит из нескольких физически разных носителей

то и dd придется повторять для каждого.

то каков порядок восстановления из ранее созданной копии с помощью rsync в случае неожиданно полного уничтожения устройства?

собрать (смонтировать) целевую структуру и востановить через rsync

Это не бекап, но нет. Ничего критичного не произойдет… разве, если, чтио у тебя на хосте крутится Postgres, базу может похѐрить

Маленький диск на который никто не пишет это частный случай.

могут ли возникнуть какие подводные камни при восстановлении системного диска в будущем?

системного диска

Только у дебилов системный диск размером в 100500 гигабайт

Еще есть вопросы?

В общем и целом, восстановление системы через dd – это как неожиданно откл. и вкл. электричество (нажать reset).

Вот ниразу не откл. электричества. Откл. электричества это мгновенное действие. Чтение диска последовательно и размазано по времени, за это время на диске могут произойти изменения.

system backup через dd (комментарий)

Если делать system backup через dd во время работы самой системы (не из live флешки) могут ли возникнуть какие подводные камни при восстановлении системного диска в будущем?

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

Вообще чем и как лучше делать такой backup «на ходу»?

Явно не с помощью dd. Зачем тебе бэкапить ещё и «пустое» место, заполненное рандомом, если нужны только реальные файлы. Бэкапить лучше уж чем-нибудь вроде borg. Ну а чтобы не «на ходу», в идеале хорошо бы юзать ФС с поддержкой снапшотов. И делать сперва снапшот, а потом его бэкапить.

ТС где-то упомянул что у него пишется?

Именно по этому я и фантазирую как хочу. Гы

Именно по этому я и фантазирую как хочу. Гы

Начали вы с «Можно делать (я много раз делал).» Как-то не очень похоже на описание фантазии.

Фантазии о граничных условиях у ТСа. А так да, много раз делал копию / (у меня часто / вообще в RO, перед апдейтом можно и в RW перевести)

Фантазии о граничных условиях у ТСа.

А ТС никаких описаний этих «граничных условий» не давал.

system backup через dd (комментарий)

Это ваши «пожелалки», но ТС не подтвердил и не опроверг, что у него именно так. Опять-таки /usr тоже вроде как системный, но он может быть отдельным разделом. Да, в него ничего не пишется, но сколько занимает этот раздел и сколько на нем свободно вы не знаете. Вот посмотрел на одной машинке, раздел 30Гб из них занято 5.1Гб. Потом посмотрел на другой 64Гб, занято 51Гб из которых 24Гб это /usr/src. Так вот даже на второй машинке копия с помощью dd это лишние 13Гб.

… c в случае неожиданно полного уничтожения устройства?

Вот для этого случая и нужно созданный бэкап-файл ( backup-$DATE.tar.gz ) сразу же скопировать на отдельный бэкап-сервер!!!

sshpass -p "$B_PASS" rsync -aAXv $BACK $MOUNT

tar -czvf backup-$DATE.tar.gz -C / $MOUNT

[ ! -f /root/.ssh/id_rsa ] && ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N ""

cat /root/.ssh/id_rsa.pub | sshpass -p "$B_PASS" ssh -T root@$BACK_SERV ‘sh -c "cat - >>/root/.ssh/authorized_keys2"’

sshpass -p "$B_PASS" ssh -T root@$BACK_SERV mkdir -p $MOUNT

sshpass -p "$B_PASS" scp backup-$DATE.tar.gz root@$BACK_SERV:$MOUNT

… это только направление как это можно сделать!

:-)))

dd позволяет человеку не напрягаться с восстановлением. Не надо вспоминать как там было всё размечено и что там было в менеджере загрузчика, хотя бы это… Поэтому, полагаю, такой вопрос и возникает. Кроме того, создание архива - это тоже не мгноаенная операция. Пока вы затариваетесь в одном месте, в другом уже затариваться нечем. Так и в чём принципиальное отличие dd от tar?

Ну вот мы от «невозможности» делать бэкап при помощи dd перешли к «лишнему» месту

Забавно

Ну вот мы от «невозможности» делать бэкап при помощи dd
перешли к «лишнему» месту

Не перешли, а дополнили копилку минусов.

Минусов море. Но это не отменяет возможность делать бэкап системного диска при помощи dd

не отменяет возможность делать бэкап системного диска при помощи dd

Ну можно и в hexeditor открыть /dev/disk-source и /dev/disk-destination и вручную перебивать байтики. Тоже такая возможность имеется.