Backup VSS и файловых архивов

Версионное хранилище VSS от Microsoft обладает многими недостатками, но все же по тем или иным причинам может использоваться и имеет ряд уникальных особенностей (оригинальную систему меток например) и весьма неплохой GUI клиент. К сожалению, версионное хранилище основано на использовании файловых ресурсов и подвержено разного рода проблемам при парраллельной работе. Ситуация усугубляется тем, что штатные средства проверки и резервирования так же весьма далеки от совершенства и крупные БД зачастую приходится резервировать при помощи обычного файлового копирования (это рекомендация от MS).

В этой статье я расскажу о применении архиватора 7-Zip для решения задачи backup по расписанию в отношении БД VSS или других крупных файловых архивов подверженных более или менее медленным изменениям (например, архивов документации расположенной на WEB-сервере). Целью является выработка такой процедуры backup, которая бы позволяла с небольшими усилиями восстанавливать состояния архива на любой момент времени с точностью порядка суток и более и при этом не требовала чрезвычайно много места для хранения.

Допустим размер нашего файлового хранилища 5 Гб и порядка 200000 файлов. Если мы будем просто копировать файлы или фоспользуемся каким-нибудь средством типа NT-Backup "по-простому", то суточные архивы за год будут весить 5 * 365 Гб > 1.5 Тб, что никуда не годится. Мы конечно можем сжать наши файлы, пусть даже, до размера 800 Мб (это реалистично при хранении исходных кодов), но всеравно 300 Гб в год выглядят нескромно, особенно если ежедневных изменений не так много (многолетний архив документации).
Это приводит нас к разностным backup, те backup которые выполняются не только на основе содержимого файловой системы, но и с учетом предыдущего backup. То есть резервируется разница. Этот метод будет эффективен как в отношении файловых архивов, так и БД VSS. В качестве "базы" для создания разностного backup может выступать как предыдущий разностный backup, так и полный. Если последовательно создается несколько разностных backup один на основе другого, то всегда резервируются самые свежие изменения (минимальный размер), однако в случае чего, восстанавливать придется так же - накатывая один backup поверх другого. Лично мне такой подход не нравится - чем длинее цепочка, тем она сложнее и опаснее. Поэтому здесь я буду рассматривать разности только относительно предыдущего полного backup - это будут добавочные (кажется термин NT Backup) или накопительные backup. Для восстановления backup нам понадобится ближайший снизу (по дате) полный backup и возможно один добавочный backup.

Подобные Backup могут делать различные средства, типа упомянутого NT Backup. Но здесь я рассмотрю более простое средство - архиватор 7-Zip. Этот архиватор отличается не только высокой эффективностью сжатия, поддержкой юникода, что важно для киррилических имен, UTC временем изменения файлов, но и достаточно широким набором опций по формированию архивов. В том числе в нем присутствует такой объект как анти-итем - это запись о файле или каталоге, которая при распаковке архива поверх содержимого каталога приводит к удалению этого файла или каталога.

Рассмотрим комманду

7z u Full.7z -u- -up0q3x2z0!Add.7z C:\Data -x@vss_ex.txt -mx3

Здесь:

u Full.7z - комманда обновления базового (полного) архива Full.7z
-u- - ключ, указывающий, что мы будем писать изменения не в сам архив Full.7z, а в отдельный архив с изменениями.
-up0q3x2z0!Add.7z - после -u описание особой обработки ситуаций:
p0 - файл есть в архиве, но не подпадает под маску - игнорируем (0);
q3 - файл есть в архиве, но нет на диске - создаем анти-итем для удаления при распаковке (3);
x2 - файл в архиве новее, чем на диске - добавляем в новый архив (2) - для нас важно именно текущее состояние;
z0 - файлы в архиве и на диске одинаковы - игнорируем (0) - нам нужны только изменения;
!Add.7z - указание на разностный архив Add.7z, который будет создан
C:\Data - директория с нашим файловым хранилищем
-x@vss_ex.txt - указание на файл со списком путей-исключений (по умолчанию в UTF-8!).

Данная комманда позволяет сформировать добавочный архив для полного архива Full.7z. Этот добавочный архив будет содержать разницу между содержимым Full.7z и текущим состоянием файлового хранилища. Для восстановления данных надо распаковать Full.7z, а затем, поверх его данных, Add.7z. Более подробное описание команд смотрите в документации 7-Zip.

Таким образом, мы имеем инструмент, позволяющий создавать обычные Backup (обычный архив 7-Zip) и добавочный к нему (приведенная выше команда). Остается определится с запуском этих команд, выбором имен, расписанием. Я выбрал такой сценарий:

Имя для полного backup выбираю YYYY.MM.DD.7z, а для добавочного YYYY.MM.DD.add.7z. Таким образом все архивы упорядочены по имени - она же дата и можно легко отличить полный от добавочного.
Backup произвожу раз в сутки (если чаще - надо доработать именования), полный он или добавочный передаю параметром в командный файл его формирующий. Командный файл может легко получить предыдущий полный backup из каталога с уже имеющимися backup по файловой маске ????.??.??.7z (последний в сортированном списке таких файлов) и использовать его для формирования добавочного.
Понятно, что как минимум один полный backup должен быть сформирован перед тем, как можно будет формировать добавочные. Чем больше изменений в файловом хранилище, тем больше и больше становятся эти добавочные архивы. Поэтому время от времени надо формировать очередной полный backup (это методика похожа на ключевые кадры, используемые при сжатии видео). В своем конкретном случае, я делаю один полный backup в неделю и 6 добавочных для остальных дней. Для этого регистрируется пара заданий в Windows Task Sheduller для запуска командного файла.

Прикинем экономический эффект. Чем дальше от полного backup, тем больше изменений в очередном добавочном. В моем случае среднее (типичное) значение добавочного архива равняется 15 Мб (в начале недели существенно меньше, в конце - больше). В году 52 недели. Итого размер: 52 * 800 + (365 - 52) * 15 - чуть более 45Гб в год при доступности архива на любой момент времени с точностью до суток. Для еще большего уменьшения объема можно конечно "прореживать" backup - удалять часть промежуточных дополнительных и, возможно, полных backup далеко отсоящих от текущей даты. Сущствуют подходы типа "револьверного" backup, когда устанавливают некоторый максимальный интервал между backup в зависимости насколько они отстоят от текщей даты. Например: последние 3 месяца - раз в сутки, последний год - раз в неделю, ранее - раз в месяц. Организовать автоматическое управление файлами backup по такой схеме не так сложно, но в моем случае этого не потребовалось - объем и так нарастает не быстро.

Отмечу еще некоторые нюансы

При проведении backup желательно иметь максимально монопольный доступ к файлам - временно отключить файловые шары и сервисы, которые могут обращать к резервируемым файлам. Особенно это важно для VSS.
При резервировании VSS полезно совместить с полным backup проведение проверки целостности (analyze). Только backup надо выболнять до проверки, тк analyze склонен к падениям и зависаниям. Кроме того имеет смысл предусмотреть задание с командой прибития процесса analyze по истечении некоторого времени, на случай если он явно зависнет (он при этом може блокировать файлы).
Полезно настроить уведомления об ошибка backup себе на почту и вести логи операций.
При backup по сети и сбое при обращении к сетевому ресурсу может быть содан архив без единого файла. Если это полный архив, то последующие добавочные на самом деле будут так же полными, и лучше получив уведомление об ошибке разобраться с этой ситуацией, чтобы не тратить зря место.
7-Zip не панацея - он удобен как средство объединяющее хороший компрессор с возможностями добавочного архивирования. Однако специализированные программы типа NT-Backup имеют все же больше возможностей по резервированию, и в некоторых случаях (например, при резервировании ОС) желательно использовать именно их.

Ссылки

Пример командного файла, реализующего подобную стратегию резервирования
7-zip.org - сайт архиватора 7-zip

30.09.2010 - 12.10.2010