Резервное копирование сервера и нескольких клиентов
Я использую сервер Amahi. Это в основном Fedora14 x64. Я ищу хорошее решение для резервного копирования моего системного диска 200 ГБ на сервере на внешний диск USB/eSATA каждую ночь. Я изучал использование dd, но, поскольку на сервере одновременно могли выполняться другие функции, он не был достаточно безопасным. Я хотел бы, чтобы резервные копии были инкрементными, поэтому последующие резервные копии после начальной будут довольно быстрыми. Резервная копия также должна быть загрузочной, иначе она сможет создать загрузочный диск после загрузки с компакт-диска или чего-то еще.
Я также хотел бы, чтобы сервер мог делать аналогичные резервные копии моих клиентов под управлением Ubuntu, Windows 7 x64, Windows 7 Starter, OSX Lion, Windows XP и так далее. Поэтому никакие приложения не создают резервные копии только общих папок или чего-то в этом роде. Я предполагаю , что должен существовать клиентский демон, который заблокировал бы систему, чтобы сделать возможным резервное копирование системного диска Windows, который в противном случае может быть довольно капризным.
Загрузка компакт-диска в сбойном клиенте и подключение к серверу, восстановление последней резервной копии и запуск - моя идеальная цель.
Есть ли что-нибудь, что соответствовало бы этим потребностям?
2 ответа
Я бы сказал, что вам нужно другое решение для резервного копирования для каждой операционной системы.
Для восстановления Linux вам обычно не нужно изображение (хотя оно может быть быстрее). Сохранение всех файлов с разрешения достаточно для восстановления загрузочного Linux. Поэтому я предлагаю использовать BackupPC или резервное копирование, инициированное клиентом, используя rsync/tar/dar. Вы можете создавать согласованные резервные копии Linux, используя LVM. Если вы еще не использовали LVM, вам необходимо переустановить. Смотрите BackupPC + LVM.
Я не знаю много о Mac, но TimeMachine, кажется, достаточно хорош для ваших целей. С помощью некоторых хакерских атак вы можете использовать Linux в качестве цели TimeMachine. Если вы хотите испытать Apple plug'n'play(TM), вы должны купить коробку машин в реальном времени;)
Для 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), которые не имеют сложных разрешений файловой системы / расширенных атрибутов, но, вероятно, не подходят для системных файлов.