Резервное копирование системы
 

Доброго дня.
Есть дебиан 6.0.5. установил на железку от Kraftway.
Хочу кое-что там протестировать. Но вот вопрос: как в Linux делать резервное копирование системы?
т.е. после установки я настроил окружение, время, ещё кое-что. И хотел бы сделать копию системы, как System State в Windows.
т.е. при неудачном тестирование не пришлось переустанавливать, а просто откатится назад.
Спасибо.

Я снимаю образ всего раздела, для этого гружусь с флешки (подойдёт любая Live система) и дальше так:

Создание файла с нулями нужно для лучшей сжимаемости, в отдельных случаях так можно сэкономить процентов 30 объёма итогового сжатого образа. Вместо gzip я лично использую pigz - многопоточную версию gzip, которая на многоядерных процессорах сокращает время снятия образа раза в полтора. Распаковка делается так:

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

а можно без загрузки с флешки? прямо из системы? и настроить в кроне?

Тут смысл в том, что в "активной" системе какие-то файлы постоянно изменяются. В итоге, получается неточная копия.

Насколько могу судить, копирование с 'dd' — очень медленный процесс, особенно с использованием маленького размера блока.
Есть стандартная юниксовая программа 'dump' (и 'restore' для восстановления). Но, вроде, в Linux, в отличие от FreeBSD, не делает копию системы "на живую".
Посмотрите 'fsarchiver'. У него есть опция бэкапа работающей системы.

Если рассматривать вопрос буквально: "просто откатиться назад", то нужно использовать LVM или Btrfs.

ааа так вот зачем LVM... пойду, почитаю об этом. Спасибо.

Сделать копию и синхронизировать её с актуальным состоянием файловой системы можно командой "rsync".

AMDBulldozer, так а копию как тогда делать лучше?

В любом случае быстрее, чем пофайловое чтение, когда файлы размазаны по разделу и головка туда-сюда ёрзает. Последовательное чтение всех байтов на разделе в любом случае будет быстрее. В размер блока легко изменить: bs=8M.

Делает. Недостаток у нее в том, что работает только с ext2/3/4 так что не всем подходит. А так вполне неплохая вещь. Кстати я тут уже описывал процесс снятия полного образа системы (http://forum.oszone.net/thread-249396.html) и ее восстановления этими программами. Есть еще функция создания инкрементных образов, так что dump вполне применима для резервного копирования на серверах.

Еще fsbackup посмотреть можно.

чёт я ступил. на курсах по Линуксу дали презентацию. Сейчас туда глянул, а там есть кратенько так:
что такое telinit 1 и зачем "mount -o ro,remount /" ?
и вот ещё вопрос: как пароль вводить для подключения к серверу? Если это виндовый сервер с доменной авторизацией.

Переход в однопользовательский режим и перемонтирование корневого раздела в режим "только чтение".

Вместо 'bzip2 -9' лучше использовать 'xz' где-то с уровнем компрессии 5. И быстрее будет, и меньше объём на выходе.

Перечитал 'man dump', но не могу найти такой опции.

Тогда уж pbzip2, он умеет распараллеливаться в отличие от. Формат сохранён старый добрый bz2, то есть, объём результата будет как у bzip2 -9 (распаковывать можно и тем же bzip2).
Сферический пример в вакууме на 4-х ядрах:
Разница внушительная.

Угу.. А как и с gzip/pigz. Только вот я вчера словил глюк с pigz - не хотел распаковывать tar.gz, которых легко распаковывается обычным gzip'ом :(

А в целом это предложение не отличается от моего. mount -o ro,remount / нужно для того, чтоб на ФС в процессе копирования не было никаких изменений (то, о чём говорили выше). Только вот для уменьшения объёма образа я всё-же советую заполнить свободное место нулями (нули отлично сжимаются), особенно если его много.

Возможно у нас разные представления о значении слов "на живую". Я имею в виду, что можно делать образ работающей системы, без всяких загрузок с флэшки.
Я не уверен, как эта программа поведет себя на системе с постоянно изменяющейся файловой системой, на пример с базой данных, но вполне можно перед бэкапом на всякий случай перемонтировать нужную ФС только для чтения. Или снимать dump'ом только образ системы с настройками, а бэкап БД делать средствами СУБД.

Тогда уж pixz, он тоже умеет распараллеливаться, сохраняя все исходные преимущества.

Я тоже это имею ввиду. Во FreeBSD у dump имеется опция -L.
В Linux не вижу такой возможности.

Да, UFS2 у FreeBSD имеет встроенный механизм снэпшотов, которого нет у линуксовых фс (кроме вроде btrfs, но её не встретишь в проде пока, сыра ещё). Но это можно обойти при использовании LVM — создать снэпшот средствами LVM и бекапить его чем угодно (tar, dd, dump).
Любопытно, ещё раз запряжём нашеих сферических архиваторов в вакууме:
Прогресс налицо, но есть пара минусов: нестандартный синтаксис и то, что проект как-то вяло развивается, в официальных репах этого добра нету. К тому же говорили выше, что его у его собрата pigz проблемы с обратной совместимостью не только по синтаксу, но и с собственно архивами. Ну и оно всё равно посасывает по скорости у pbzip2, у которого никаких проблем с обратной совместимостью я не замечал.

Kent, такой опции действительно нет, но мне довелось делать этой программой бэкап работающего первичного DNS сервера без каких либо специальных опций. И восстановление прошло успешно. Образ использовался для подготовки резервного сервера, который после косяка при обновлении системы на основном, сутки проработал без каких либо нареканий.

Синтаксис pigz полностью обратно совместим с gzip. Отличие только в дополнительных опциях, управляющих потоками. Что касается совместимости с архивами, то это похоже просто баг. Столкнулся я с этим впервые, хотя использую pigz в качестве основного gz-архиватора уже больше года. Ошибка выглядит так:

Сам архив, если интересно, находится здесь.