Какие инструменты вы бы использовали для проверки целостности и целостности восстановленной файловой структуры? Моя среда - это файловый сервер Windows Server 2008. (Мы используем ленту для резервного копирования, но это несущественно.)
Я специально ищу инструмент, который:
Немного предыстории: недавно мне пришлось заменить диски на нашем файловом сервере. Обновление планировалось начать через 36 часов после последнего полного резервного копирования, поэтому я создал дифференциальную резервную копию. Однако оказалось, что одно из наших приложений очищало бит архива для файлов, сохраненных на сервере, поэтому они не были включены в дифференциальную резервную копию. Я не знал об этом, пока мои пользователи не сообщили об отсутствии некоторых файлов.
Помимо этого, существуют ли другие распространенные методы проверки целостность полнота восстановления? Мне часто говорят, что тестирование резервных копий путем их восстановления - единственный способ узнать, что резервные копии работают, но как вы справляетесь со случаем, когда оно работает на 99% правильно, а другой 1% не работает?
Обновить: Видимо мне нужно кое-что прояснить.
Я уже знаком с расхожим мнением, что «лучший способ проверить резервную копию - это восстановить». Это необходимый шаг, но его НЕ достаточно. Возможность восстановить файлы, из которых вы сделали резервную копию, НЕ гарантирует, что все файлы, которые вам нужны, были изначально зарезервированы. Это проблема, которую мне нужно решить.
В Linux доступно множество инструментов, которые хорошо подходят для этой задачи. Ты можешь использовать mount.cifs для монтирования общих папок Windows на хосте Linux, или вы можете просто запустить Cygwin прямо на файловом сервере.
Перед запуском резервного копирования используйте find команда для рекурсивной итерации из указанного каталога и записи результатов в файл. Этот список можно сохранить вместе с резервной копией для использования в будущем.
find /path/to/dir > list_before.txt
Если вы хотите, чтобы контрольные суммы рассчитывались для каждого файла, просто передайте вывод через md5. Эта команда показывает только имена файлов, потому что для папок хеши не нужны.
find /path/to/dir -type f -print0 | xargs -0 md5 > md5_before.txt
После восстановления резервной копии создайте еще один список файлов с помощью той же команды, затем используйте diff найти различия между ними. В идеале эта команда не должна выдавать никаких результатов.
diff list_before.txt list_after.txt
Backup Exec (в последних версиях) по умолчанию должен проверять после резервного копирования. Однако дважды проверьте это, должен быть флажок в параметрах.
Вы можете посмотреть на параметр «Записывать контрольные суммы на носитель», чтобы сохранять контрольные суммы после каждого резервного копирования, и подумать о сохранении журналов заданий для сравнения от запуска к запуску. Я не знаю формата этих файлов, но вы можете получить списки файлов или, по крайней мере, сведения о размерах для сравнения в качестве отправной точки.
Прежде всего, включите опцию «проверить» в выбранном вами приложении для резервного копирования, а затем продолжайте резервное копирование, когда это возможно.
Вы можете использовать дополнительные приложения для выполнения всех необходимых действий, но они будут длиться столько же, сколько и резервная копия. Может быть, что-нибудь добавить к загруженности ваших серверов в выходные дни?
Я использую комбинацию методов для резервного копирования. Я использую резервное копирование в режиме онлайн, а также еженедельно делаю образы своих рабочих серверов. Я провожу тестовое восстановление ежемесячно случайных файлов, таких как базы данных SQL, прикрепляю их и проверяю их работоспособность.
Используя свои образы, я делаю резервные копии P2V своих серверов, используя SCVMM в большой SAN. Для тестирования аварийного восстановления я могу вывести их все в отдельную IP-среду. Если сервер когда-либо физически выйдет из строя, я могу вызвать виртуальную машину сервера, которой всегда меньше недели, и восстановить любые расхождения из резервной копии онлайн. У меня также есть одна машина XP, присоединенная к домену, который находится в этой закрытой среде, где я могу тестировать все свои приложения и электронную почту. Я делаю это каждые 6 месяцев или около того, чтобы обеспечить хорошую среду аварийного восстановления.
Лучший способ проверить резервную копию - восстановить ее. Все остальное - это компромисс - в компромиссах нет ничего плохого, но вам действительно нужно восстановить данные для тестирования.
В идеальном мире вы должны выполнять аварийное восстановление каждые 6-12 месяцев и чаще восстанавливать случайные файлы, но любая процедура, в которой вы восстанавливаете хотя бы один сервер на виртуальной машине и проверяете, что он загружается впоследствии, - отличное начало. .
Это то, что ты бы сделал к тому же к любой процедуре проверки, которая есть в самом программном обеспечении резервного копирования.
Не то, что вы хотите услышать, но у меня есть роскошь эталонных сред с соотношением 1: 1 для всех моих платформ именно для таких тестов.
Извините, не могу оставить комментарий.)
Насколько я могу судить (я не любитель Windows), решение Ника должен работать в Windows "изначально" (просто найдите и получите UnixUtils для win32 или любой аналогичный пакет).
Вы также можете diff каталоги напрямую (опционально с завершающим > difffile):
diff -r /path/to/what-to-backup /path/to/restored-data
Я бы восстановил файлы в тестовом месте и использовал бы такой инструмент, как Winmerge:
http://lifehacker.com/290657/compare-and-merge-files-and-folders-with-winmerge
чтобы сравнить их с первоисточником. Еще есть Windiff:
http://www.computerperformance.co.uk/w2k3/utilities/windiff.htm
Я бы также порекомендовал создать резервную копию ваших ценных данных тремя разными способами, особенно если вы не проверяете резервные копии каждый день. Я бы посоветовал Backup Exec на ленту, резервное копирование файла rsnapshot вне офиса и резервное копирование на диск:
http://backuppc.sourceforge.net/
работает локально. Попробуйте Backuppc, вы меня поблагодарите. Когда что-то пойдет не так, вы оцените разнообразие вариантов.