Начнем с простого. Люди делятся на 2 категории - которые делают резервные копии, и которые еще не теряли свои данные. Причины утери данных могут быть самые различные - как, например, банальный выход из строя жесткого диска с базой данных, так и такие относительно экзотические, как вынос сервера ворами, залив сервера прорванным отоплением или случайная порча базы в процессе ее обновления.
Я думаю, что агитировать читающих данную статью за создание копий не следует, поэтому расскажу о том, какой метод создания резервных копий я использую.
Место хранения.
Вероятно, все понимают, что хранение резервных копий на том же логическом диске, что и рабочей базы, является плохой идеей - какие-либо проблемы с логической структурой диска, и не будет ни базы, ни копии. Так что вариант "храним данные на диске D, только в другом каталоге" исключаем сразу.
Следующий вариант - другой логический диск на том же физическом. Этот вариант имеет смысл рассматривать всерьез только в очень бюджетных инсталляциях - когда, например, используется мини-сервер 1С на 5 подключений, а база занимает до 1 гигабайта. В таком случае можно хранить резервные копии в отдельном разделе, только следует делать копии еще и в какое-нибудь облачное хранилище. Какое - каждый может определить для себя сам. Самые популярные варианты - Яндекс диск и Google Drive. Они дают небольшое количество гигабайт под хранилище, но удаленные файлы складывают в корзину, поэтому время от времени процесс фактического сохранения данных в облаке требуется проверять. Иначе после аварии может оказаться, что весь объем хранилища занят находящимися в корзине резервными копиями месячной и более давности, в результате чего самая свежая копия у нас только за прошлый месяц. Если же размер файлов резервных копий не позволяет нам держать в облаке все резервные копии - рекомендую определиться с определением того, за какой период времени мы можем позволить себе потерять данные. Может быть, нас устроит еженедельная копия. В таком случае стоит создать дополнительный каталог для резервных копий, и уже этот каталог синхронизировать с облачным хранилищем. Если вам не хватает емкости облачных сервисов в бесплатном варианте - то либо вы переоцениваете собственные данные, либо вам все-таки стоит раскошелиться на отдельный жесткий диск.
Более продвинутый вариант - использование дополнительного жесткого диска. Если у вас есть 2 жестких диска, особенно если они одинаковые, может возникнуть желание объединить их в RAID1 (зеркало). А уже полученный том разбить на 2 части - для базы и для резервных копий. Но, на мой взгляд, в случае выхода данного RAID-массива может возникнуть проблема к доступу к любому логическому диску, в результате чего мы потеряем и данные, и копии. Поэтому разносим данные и копии по физическим дискам. В отличие от вышерассмотренного варианта, у нас сохраняется информация в случае выхода из строя любого из дисков, а возможная потеря данных уменьшена до времени между 2 копиями.
Отдельно отмечу тот факт, что на серверах, которые представляют собой уже настоящий сервер, достаточно часто встречаются аппаратные RAID-контроллеры, к которым подключено достаточно большое количество физических жестких дисков. В таком случае RAID массив обычно нарезают на логические диски. У администраторов может возникнуть желание выделить в таком массиве раздел под хранение резервных копий. И даже его зазеркалить. Но надо учитывать тот факт, что из строя может выйти сам RAID-контроллер. И как тогда с него списать данные? Конечно, данные (пока еще) не пропали, но доступ к ним сильно затруднен. Возьмите средней руки администратора, который больше программист-администратор 1С, чем системный администратор. Вполне вероятно, что при попытке получения данных с сервера с неисправным RAID-контроллером он или окончательно разрушит данные, или же процесс восстановления данных затянется до неприемлемых сроков. "Слава богу, что такие контроллеры еще есть на рынке, мы сегодня получим счет на новый контроллер, завтра его оплатим, и к концу недели он будет у нас" - вариант рабочий, но долгий. Поэтому я считаю, что доступ к резервным копиям должен быть как можно более простым - допустимо хранить их на выделенном диске, подключенном к обычному SATA контроллеру, чтобы в случае проблем достаточно было подключить диск к другому компьютеру / серверу и считать данные.
Сам же я использую еще более усложненный вариант. Современные серверные версии Windows позволяют подключать сетевые диски по протоколу iSCSI и работать с ними как с обычными физическим - то есть создавать тома, форматировать их и т.д. С точки зрения операционной системы они выглядят именно физическими дисками. Поэтому если в организации есть сервер для хранения резервных копий - если он поддерживает данный функционал, то рекомендую им воспользоваться. В случае выхода из строя основного сервера, можно подключить это iSCSI диск к другому серверу за считанные минуты, в результате период простоя пользователей может быть минимальным.
Составление циклов
С тем, где хранить - мы определились, теперь давайте определимся, как часто мы будем делать резервные копии.
Конечно, только вы знаете особенности работы вашего сервера 1С и требования к сохранности данных. Сервер может как использоваться круглосуточно, так и использоваться 5 дней в неделю с 8 до 17. В любом случае можно дать общие советы по организации расписания резервного копирования.
2 основных типа создания резервных копий - это журнал транзакций и полная копия. В журнал транзакций включаются данные, которые изменялись с момента снятия предыдущей копии. Копии журнала транзакции не являются накопительными - если мы сделали полную копию в 12 часов ночи, а потом каждый час делаем копию журнала транзакций - чтобы восстановить базу на 12 часов дня нам потребуется восстановить полную копию и 12 журналов транзакций. Но мы можем восстановить базу на любой момент времени, который входит в данный промежуток. Так, например, если в силу каких-то причин нам надо восстановить базу по состоянию на 6:28, мы можем восстановить базу из полной копии, последовательно накатить журналы транзакции и прийти к нужной временнОй точке. MS Management Studio позволяет прямо выбрать требуемый момент времени, после чего определяет список требуемых для восстановления журналов.
Полная копия базы данных представляет собой полную копию на момент времени. Она не позволяет восстановить данные на любой период времени, но она самодостаточна - если у нас есть файл полной копии, нам больше ничего не надо.
При создании резервных копий я использую модель увеличения интервалов. Для каждого временного интервала копий создается свое задание со своим расписанием, в рамках которого очищаются устаревшие копии предыдущего интервала. Копии каждого интервала имеют свое расширение, что позволяет легко определить, какие файлы к какому набору относятся.
А теперь рассмотрим эту схему поподробнее.
Я использую следующие уровни:
1. час
2. день
3. неделя
4 месяц
5 квартал
6 год
Если максимальный период возможной потери данных небольшой - допустим, полчаса-час, то в базе однозначно требуется включить полную модель восстановления и делать резервные копии журналов с заданной частотой. Это у нас резервные копии уровня 1. на данном уровне мы только делаем резервные копии журналов, ничего не очищаем. Обычно копии журнала транзакций имеют расширение trn. Если предприятие работает не круглосуточно, то копии журнала можно делать ежечасно, но только в рабочее время, захватывая по 1-2 часа до и после рабочего времени. Хотя в очередной раз повторю, что выбор частоты создания копий зависит от специфики работы предприятия и определяется самим администратором.
Ежедневные копии (уровень 2) делаются каждый день, в часы наименьшей загруженности, в формате полной копии. Если по выходным предприятие не работает, вполне нормально делать копии только по субботам, а воскресенье оставить для других заданий. А если сервер выключается на выходные или на ночь - то копии надо делать в обеденный перерыв или другие малонагруженный период времени. Для ежедневных копий вполне нормально оставить стандартное расширение для копий - bak. После создания самой копии, в случае успешного ее окончания, настроена очистка для файлов резервных копий первого уровня - файлов trn - старше 2 суток. Таким образом, за последние 2 суток мы можем восстановить базу на, практически, любой момент времени.
Еженедельные копии (уровень 3) мы делаем либо в определенный день недели, например, воскресенье. Только надо внимательно смотреть, чтобы разные задания не пересекались. А если они приходятся на один день - запускать их в разное время. Для копий данного уровня мы устанавливаем расширение week и очищаем ежедневные копии старше 2 недель.
Ежемесячные (уровень 4) настраиваются аналогично, только запускаются они раз в месяц, файлы имеют расширение month и очищаем предыдущие копии старше 3 месяцев. Рекомендую запускать задание не в конкретное число, а в конкретный день недели, например, первое воскресенье месяца.
Квартальные и годовые копии можно создавать по желанию. У меня квартальные копии имеют расширение quartal и очищаются ежемесячные копии старше 2 кварталов (6 месяцев), а годовые копии имеют расширение year и очищают квартальные копии старше 2 лет.
Таким образом мы имеем автоматическую систему, которая будет хранить копии за любой разумный период в разумном объеме.
Некоторые трюки.
Место на сервере резиновым не является, поэтому мы можем использовать некоторые трюки для оптимизации места под хранение данных. В Windows Server 2012 появилась новая функция, под названием дедупликация. Что это такое? Рассмотрим обычный вариант - пользователи хранят в своей папке на сервере, к примеру, телефонный справочник. У большинства из пользователей справочник будет одинаковым, но каждый из них будет занимать место. Дедупликация в Windows - это специальный сервис, который запускается время от времени, анализирует новые и измененные файлы, ищет в них одинаковые части, в результате чего на диске оставляет общее содержимое в 1 экземпляре, а остальное возвращает операционной системе в качестве свободного места. Алгоритмы Windows достаточно продвинутые, позволяют анализировать файлы не только целиком, но и частями. В результате чего при использовании дедупликации мы можем сэкономить достаточное количество свободного места. Для того, чтобы воспользоваться данной функцией, следует установить компонент Windows "Дедупликация данных", и включить ее для тома с резервными копиями. Если вы хотите заранее оценить эффект от дедупликации - можете скачать программу ddpeval с сайта Microsoft, запустить ее для выбранного диска или каталога, и программа проанализирует и сообщит, сколько места можно освободить в результате дедупликации.
Следующий момент, связанный с дедупликацией данных - если вы решите ее использовать - рекомендую отключить сжатие резервных копий (кроме журнала транзакций). Это связано с тем, что сжатые в архив файлы с небольшими изменениями в исходных данных могут дать практически несовпадающие архивы. Поэтому сжатые архивы плохо дедуплицируются. А так как резервные копии содержат много одинаковой информации, файлы с этими копиямы должны прекрасно дедуплицироваться. Так, например, у меня на одном из серверов базы данных на диске емкостью 2048 Гб хранятся резервные копии объемом 440 Гб и свободно еще 2009 Гб. То есть 440 Гб физически занимают 39 Гб, то есть дедуплицированы практически в 11 раз.
Однако есть и некоторые ограничения. Дедуплицированные диски можно подключать только к компьютерам с операционной системой, их поддерживающей. В противном случае мы рискуем разрушить данные на диске и вместо восстановления потерять их. Так что рекомендую держать если не сервер под горячую замену, так хотя бы виртуальную машину с установленной Windows 2012 и включенной дедупликацией. Это позволит в случае аварии запустить виртуальную машину, дать ей доступ к физическому диску с копиями или же к iSCSI хранилищу и спокойно списать требуемые копии.
Если есть возможность - держите сервер или хотя бы выделенную персоналку настроенную для работы в качестве сервера. Если с боевым сервером что-то случилось - первым делом оцениваем, возможно ли устранение проблемы "здесь и сейчас", или же проблему не удастся устранить за определенное время. Тогда достаточно будет воткнуть диск с данными базы данных или хотя бы копиями в резервный компьютер, затем переименовать его, чтобы при поиске сервера мы находили его, переткнуть ключ с сервера 1С в резервный сервер или же переактивировать его в случае программной лицензии, восстановить базы данных, создать базы 1С - и пользователи смогут продолжать свою работу. Да, производительность упадет, но пользователи будут работать, а вы получите возможность уже в относительно спокойной обстановке восстановить рабочий сервер.
Имейте план восстановления! Вы можете в целом представлять что и как делать при восстановлении, но в ответственный момент вы можете что-нибудь перепутать и уже безвозвратно потерять данные. Или вы можете быть в отпуске или недоступны.
Надеюсь, данная статья поможет разобраться с принципами создания резервных копий для своего предприятия, поспособствует созданию плана восстановления данных и, в конечном итоге, поспособствует более стабильной и уверенной работе. Комментарии, предложения и замечания приветствуются.
