Я управляю Амахи сервер. Это в основном Fedora14 x64 монтаж. Я ищу хорошее решение для резервного копирования моих 200 ГБ системный диск на сервере на внешний USB / eSATA ездить каждую ночь. Я изучал использование дд но поскольку на сервере одновременно могут работать и другие вещи, это было небезопасно. Хотелось бы, чтобы бэкапы были добавочный так что следующие резервные копии после первоначального будут довольно быстрыми. Резервная копия также должна быть загрузочный или, возможно, сможет создать загрузочный диск после загрузки с компакт-диска или чего-то еще.
Я также хотел бы, чтобы сервер мог делать аналогичные резервные копии моих клиенты под управлением Ubuntu, Windows 7 x64, Windows 7 Starter, OSX Lion, Windows XP и так далее. Так что никаких приложений только резервное копирование общие папки или что-то вроде того. Я предполагаю клиентский демон должно было бы существовать, что бы заблокировать систему чтобы сделать резервную копию системного диска Windows, который в противном случае может быть довольно странным.
Моя идеальная цель - загрузить компакт-диск в неисправном клиенте и подключиться к серверу, восстановить последнюю резервную копию и начать работу.
Есть ли что-нибудь, что соответствовало бы этим потребностям?
Я бы сказал, что для каждой операционной системы вам нужны разные решения для резервного копирования.
Для восстановления linux обычно не нужен образ (хотя он может быть быстрее). Сохранения всех файлов с разрешением достаточно для восстановления загрузочного Linux. Поэтому я предлагаю использовать BackupPC или резервное копирование инициировано клиентом с помощью rsync / tar / dar. Вы можете создавать согласованные резервные копии Linux с помощью LVM. Если вы еще не использовали LVM, вам необходимо переустановить его. Видеть Резервный ПК + LVM.
Я мало что знаю о компьютерах Mac, но TimeMachine, кажется, достаточно хорош для ваших целей. Вы можете с помощью некоторого взлома использовать Linux в качестве цели TimeMachine. Если вы хотите получить опыт Plug'n'Play (TM) Apple, вам следует купить коробку для машин в реальном времени;)
Для Windows вы можете использовать встроенное резервное копирование образа (в Win 7) в общий сетевой ресурс на домашнем сервере; Перейдите на Windows Home Server (у которого есть такой клиент, о котором вы упомянули). Или вы используете UrBackup, у которого есть CD для восстановления по сети.
Получить идеальный снимок при работающей системе unix сложно. Вы можете перезагрузить / перейти на уровень запуска, на котором мало что работает, чтобы все перешло в безопасное состояние. В противном случае у вас всегда будет некоторый риск того, что резервные копии не совсем совпадают, как вы сами говорите.
Для инкрементного резервного копирования unix (linux и os x) вы можете посмотреть rsync. Вокруг него есть различные оболочки более высокого уровня, но в основном:
rsync / destsrv: / mnt / backup / snap-20110905 --link-dest = / mnt / backup / snap-20110904
создаст новое дерево в / mnt / backup / snap-20110905, содержащее все файлы, но если они не изменились по сравнению с предыдущей резервной копией (заданной в link-dest), они будут жестко привязаны к этому каталогу, а не скопированы. Таким образом, вы сохраните вчерашний снапшоп и сегодняшний моментальный снимок, чтобы они делили столько, сколько можно. Так что он соответствует твоему добавочный требование.
Это не даст вам загрузочного снимка, хотя вы сможете легко скопировать файлы на новый диск и сделать его загрузочным. Это ваше вторичное загрузочный требование.
rsync будет работать через ssh, поэтому, пока вы можете передавать ssh от клиента на сервер резервного копирования, вы можете выполнять резервное копирование ряда систем на основе unix на один и тот же сервер резервного копирования.
Я понятия не имею, как это будет работать под Windows (например, cygwin). Я предполагаю без дальнейшего исследования, что это вообще не сработает. Я думаю, это было бы хорошо для файлов, похожих на данные (например, Word docs), которые не имеют сложных разрешений / расширенных атрибутов файловой системы, но, вероятно, не подходят для системных файлов.