Имею на ЖД только один раздел: sda1, примонтировал его в /mnt/root, а сетевой диск на другой машине в /mnt/backup, теперь sudo tar -cvzpf /mnt/backup/ubuntu-sda1.tar.gz /mnt/root. Нормально ли должен пройти бэкап при работающей системе, каковы возможные казусы, нет ли рекурсии?
UPD.
Переименовал вопрос, так как вижу: tar: Завершение работы с состоянием неисправности с из-за возникших ошибок
При использовании команды: tar -cvpzf backup.tar.gz --exclude=/backup.tar.gz --exclude=/proc --exclude=/lost+found --exclude=/sys --exclude=/mnt --exclude=/media --exclude=/dev /
Контрольные суммы чего, дампа раздела? Если у вас директория назначения будет по NFS примонтирована, например, почему вы думаете, что у вас проблемы будут?
Давайте проверим.
Вы про какие параметры сейчас, не совсем понял?
Если упадет NFS-шара, куда архивируется tar'ом или dump'ом, по-моему, будет ровно одно и то же. Можно для надежности монтировать NFS по TCP, а не UDP. А так я не думаю, что будет какая-то разница между данными, переданными при использовании tar и при использовании dump. Компрессия опять же и там, и там есть.
Начинаю понимать, где пошел по ложному следу. Вот страница help.ubuntu.com/community/BackupYourSystem/TAR, а там раздел Backup Over a Network, вчера второпях не понял, что имеется в виду отправка неткатом после создания. Почудилось, будто сразу на удаленную машину шлет, словно по ftp, т.е. с возможностью паузы (на время сбоя сети). Кстати, такое вообще возможно?
Такое возможно разве что при таймаутах ввода-вывода, когда запись на сетевой ресурс буферизуется и передача данных возобновляется после простоя соединения. По другому не получится.
И как-то заставить при сбое останавливать tar. Глупый метод — пинг каждую секунду, если не ответили — ctrl+z на tar, когда ответили — bg на tar. Только как бы буфер сделать? Резать файл не очень хочется)
Это уже совсем другой вопрос, и тут надо по ситуации думать, как лучше его решить, это зависит от качества вашей сети, например, размер буфера зависит от таймаута и так далее. Может быть хватит памяти при использовании пайпа.
А по поводу бэкапа раздела я бы все-таки на вашем месте предпочел dump, тем более, что он умеет инкрементальные бэкапы делать, то есть сохранять только изменения с прошлого бэкапа, что позволяет не делать полный бэкап каждый раз и снижает таким образом нагрузку на систему и сеть.
И tar так может. А еще tar-ом я могу отдельно бэкапить системную инфу от профилей юзеров и в том же духе. К тому же, dump разве можно сделать на живой машине? Там не нужно монопольно захватывать девайс? А /proc/ не позволит таких шуток.
Про отдельный бэкап понятно, конечно, но вопрос изначально не так стоял. Аналогично и в дампе можно системную информацию бэкапить.
Да, можно. Он изначально для этого и предназначен, в отличие от tar.
Вы сейчас о чем по поводу /proc/? Если о том, что её нельзя забэкапить наживую, то это и не нужно, это виртуальная файловая система, создаваемая на этапе загрузки ядра, которая к корневому разделу непосредственно не относится.
tar --one-file-system забакапит только корневой раздел (без /dev и /proc естественно, правда если установка раскидана по разделам типа /usr, /var или /home, как рекомендуют некоторые устаревшие гайды, то прийдется их бакапить отдельной коммандой).
И нужно понимать, что некоторые приложения, например базы данных, бакапить обычным копированием во время их работы не рекомендуется (и даже вредно для бакапа).
Ну, grub, положим, ничего не монтирует — он загружает ядро и initramfs в память и передаёт управление вместе с командной строкой.
В общем, второй раз-то монтировали тот же самый block device? Если да, то очень зря — на такое использование рассчитаны только кластерные ФС (типа ocfs), а e* — не рассчитаны и с большой вероятностью серьёзно портятся.
Если надо получить «то же самое содержимое», но без навешанных сверху точек монтирования, делайте bind:
mkdir /mnt/root
mount -o bind / /mnt/root
В этом случае, в /mnt/root у вас будет содержимое корневой ФС, а вот /mnt/root/mnt/root, а также /mnt/root/dev, /mnt/root/proc, /mnt/root/sys и прочее будут пустыми директориями, т.к. bind привязывается к конкретной ФС а не к элементу VFS.
То было образное выражение, намекающее на тождественность запускаемой и монтируемой систем. Извините, если запутал. И итоге пришел к виду tar аргументы backup.tar.gz аргументы /
Все хорошо, но всегда заканчивает с ошибкой, интернеты говорят ее игнорировать.
