Эта проблема
Мы хотели бы сделать резервную копию наших критических файлов из нескольких общих сетевых ресурсов на съемный жесткий диск. Мы хотим автоматизировать резервное копирование, чтобы не забывать о его запуске. Это нужно закончить за ночь. Кроме того, мы хотим иметь возможность сохранять несколько версий каждого файла, чтобы мы могли легче устранять ошибки наших пользователей.
Исходная информация
Я работаю в большом предприятии на базе Windows с централизованным ИТ-отделом, который отвечает за все резервные копии. Их резервные копии предназначены для аварийного восстановления, а не для ошибок пользователя, и для любых восстановлений, не связанных с авариями, требуется одобрение руководства верхнего уровня. Несколько раз мы замечали, что наши резервные копии не работают, нас не уведомляли. У меня нет прав администратора на сервере или на рабочем столе. Мы пытаемся сделать резервную копию 198 000 файлов размером около 240 гигабайт. Эти файлы редко меняются. Наш резервный диск - один терабайт.
Мое предлагаемое решение
Я бы хотел написать командный файл, используя Робокопия с параметром / mir вместе с Mercurial SCM для хранения всех версий файла. Я бы сделал hg add с последующим hg commit перед каждым выполнением Robocopy, чтобы сохранить текущее состояние, а затем сделать зеркальную копию файловых структур. Проблема в том, что / mir удалит все папки, отсутствующие в источнике, а Mercurial сохраняет репозиторий в папке .hg в папке назначения.
Кто-нибудь знает, как я могу убедить Mercurial хранить папку .hg в другом месте или убедить Robocopy не удалять ее из места назначения?
Я стараюсь избегать написания специальной программы для копирования.
Чтобы выполнить зеркало, игнорируя определенные расширения файлов, попробуйте следующее:
robocopy c:\temp\source c:\temp\dest /e /purge /xf *.hg
Я немного протестировал его здесь, и, похоже, файлы .hg остались одни в месте назначения.
Я также рекомендую флаг / z (перезапускаемый для больших файлов), и в прошлом мне приходилось прибегать к флагу / fft при работе с серверами с разной степенью детализации по времени: http://www.readynas.com/forum/viewtopic.php?t=3573
edit: ... мой пример выше предполагал, что файлы с именем * .hg ... делали то же самое и игнорировали каталоги с именем * .hg, используйте это:
robocopy c:\temp\source c:\temp\dest /e /z /purge /xd *.hg
Поскольку вы уже говорите о Windows и robocopy, у меня есть другое решение без использования Robocopy или Mercurial. Работа за пределами сайта становится немного сложнее, но у вас, по крайней мере, будут резервные копии всех ваших критических файлов почти в реальном времени.
У вас есть два варианта для начала:
В любом случае у вас будет либо полный комплект DPM, либо, по крайней мере, программное обеспечение, которое затем можно будет установить на запасной машине. DPM отлично подходит для резервного копирования общих сетевых ресурсов, причем резервное копирование выполняется каждую минуту. Он также выполняет теневое копирование, чтобы пользователи могли использовать файлы при их резервном копировании. Наконец, он также позволяет использовать параметры восстановления для конечных пользователей, которые, если хотите, в некоторой степени избавляют вас от лишних проблем.
Если вам нужны внешние возможности, вы также можете приобрести ленточный накопитель или даже встроенный ленточный накопитель в свой модный новый сервер. Если вы предпочитаете съемный диск, обратите внимание на продукт под названием Firestreamer. Это позволяет использовать диск для съемного дискового хранилища.
В любом случае, в долгосрочной перспективе это намного лучшее решение и намного надежнее, чем задание cron с использованием robocopy и некоторого места хранения, поверьте мне! В целом ваши затраты составляют от 500 до 5000 долларов в зависимости от того, что вы хотите сделать, но это стоит спокойствия и стабильности.
Во-первых, я хотел бы указать, что вы, вероятно, принимаете проблему не с того конца: теоретически вам следует записать бизнес-обоснование для лучшего решения для резервного копирования, попросить ваше руководство отправить его в центральный ИТ-отдел, а затем позволить им разбирайтесь сами.
Теперь, когда это исключено, вы столкнетесь с рядом проблем с этим предложением. Во-первых, Mercurial не создан для того, что вы хотите делать, и не является robocopy. Вы можете найти способы обойти проблему, отказавшись от самой резервной копии как хранилища, но это не очень эффективно.
Вместо этого я бы исследовал два разных следа.
Первый - использовать теневое копирование тома для создания истории моментальных снимков, которые вы храните на другом дисковом массиве на сервере (похоже, на вашем файловом сервере запущены окна, и я предполагаю, что у вас последняя версия 2008 года или выше) . Это даст вам простой способ восстановить файлы пользователя (фактически, пользователи смогут восстанавливать свои файлы самостоятельно), сохраняя размер резервной копии, близкий к размеру данных. Обратной стороной этого является то, что вам понадобится доступ администратора на сервере, чтобы настроить это, поэтому нет никакого способа обойтись без ваших ИТ-администраторов (что я лично считаю хорошей мыслью, но это только я).
Второй вариант - прикусить пулю и получить «настоящее» программное обеспечение для резервного копирования. Если ваши данные достаточно важны, вы, вероятно, сможете обосновать свои вложения. Если нет, вы всегда можете использовать резервную копию Cobian для создания инкрементных копий файлов в качестве задачи на уровне пользователя или, если вы действительно хотите использовать mercurial, используйте резервную копию Cobian вместо Robocopy для создания копии репозитория.