gifts2017

Рекомендации по организации резервного копирования для систем с Windows Server / Windows SQL Server

Опубликовал Петр Астахов (Zebar) в раздел Администрирование - Архивирование (backup)

В данной статье мы рассмотрим работу с резервными копиями базы данных 1С, а также некоторые приемы, оптимизирующие работу с резервными копиями.

Начнем с простого. Люди делятся на 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С - и пользователи смогут продолжать свою работу. Да, производительность упадет, но пользователи будут работать, а вы получите возможность уже в относительно спокойной обстановке восстановить рабочий сервер.

Имейте план восстановления! Вы можете в целом представлять что и как делать при восстановлении, но в ответственный момент вы можете что-нибудь перепутать и уже безвозвратно потерять данные. Или вы можете быть в отпуске или недоступны.

Надеюсь, данная статья поможет разобраться с принципами создания резервных копий для своего предприятия, поспособствует созданию плана восстановления данных и, в конечном итоге, поспособствует более стабильной и уверенной работе. Комментарии, предложения и замечания приветствуются.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Антон Стеклов (asved.ru) 12.10.16 08:27
2 основных типа создания резервных копий - это журнал транзакций и полная копия. В журнал транзакций включаются данные, которые изменялись с момента снятия предыдущей копии


Вот этот абзац читать не надо. Лучше поищите нормальную статью про режимы и типы резервных копий MSSQL.
2. Dim Dragonim (Dragonim) 12.10.16 08:36
Не статья, а сборище мифов о резервном копировании.

1. Диски объединённые в рейд массив необходимо рассматривать как один (без разнице какой рейд используется), а следовательно применяются все те же правила что и для одного физического диска.
2. Делать резервные копии на ещё один физический диск (не логический) установленный в том же сервере имеет смысл, т.к. бекап на этот диск будет делаться намного быстрее чем по обычной сети, аналогично будет делаться быстрее восстановление.
3. В идеальном случае полные бекапы должны быть в трёх копиях, первая хранится на том же сервере на другом физическом диске, вторая в быстрой сети (обычно не далеко от самого сервера для более быстрого доступа), третья находится в другой местности, т.е. очень далеко от сервера. Чаще всего пренебрегают хранить копию на том же сервере на другом физическом диске, т.к. современные сети очень быстрые и/или понятие сервер и его физические диски размыто в современной компьютерной инфраструктуре.
4. Не используйте дедубликацию для бекапов, т.к. вы теряете контроль за самими бекапами и возрастает вероятность потери. Лучше задайте себе вопрос "Зачем мне так много копий базы?" и ответом на этот вопрос сохраните место.
5. Бекапы журналов транзакций это отдельная большая тема. При активном использовании 1С журналы транзакций растут как грибы, а откат больше чем на 1 сутки очень редкое явление, не говоря уже о скорости восстановления из журналов транзакций.
6. Не сказано не слово о самом главном, о тестировании созданных резервных копий. Само по себе резервное копирование это успокоение нервов админа, только проверив возможность восстановления базы из резервной копии можно говорить о сделанной работе.
3. Петр Астахов (Zebar) 12.10.16 14:09
(2). 1. Диски рассматриваются как один, но это пока у вас массив не развалился. Если у вас RAID из 10 дисков и контроллер сдох - что вы будете делать со своим массивом?
2. Почти не спорю. Только скорость обычного SATA диска - 100-150 MBps, а гигабит - дает около 100 Mbps. Так что по скорости, если приемник для бэкапов не тормозит, это все сравнимо.
4. А можете обосновать, почему при использовании дедупликации возрастает вероятность потери?
5. Соглашусь. Поэтому и пишу про их удаление через 2 дня. Почему через 2, а не через 1? Случаи разные бывают. Если место позволяет - можно и больше.
6. Да, наверное, надо было добавить. Но это совсем уже общее место.
4. Петр Астахов (Zebar) 12.10.16 14:12
(1) Антон, можете рассказать, что именно принципиально неправильного я написал? Я не спорю, что специализированная статья по резервному копированию на MS SQL будет лучше, глубже и т.д. Но человеку, который переходит с файлового варианта на SQL обозначенные понятия будут достаточны, чтобы в общих чертах разобраться.
5. Dim Dragonim (Dragonim) 12.10.16 15:11
(3) Zebar,

1. Я хотел сказать что все ваши абзацы про рейд можно заменить одной фразой "С точки зрения резервного копирования данных любой рейд массив надо рассматривать как один физический диск и применять к нему все те правила которые вы бы применили при резервном копировании на физический диск".
4. Во-первых, вы сами написали "Дедуплицированные диски можно подключать только к компьютерам с операционной системой, их поддерживающей. В противном случае мы рискуем разрушить данные на диске и вместо восстановления потерять их.", а это уже значит что идея хранить тут бекапы плоха, т.к. не факт что восстанавливать данные будете именно вы, не факт что в этот момент вы будете трезвы, не факт что вы вспомните про такую особенность, не факт что у вас имеется подходящая система под рукой чтобы быстро развернуть бекапы. Есть такое правило: "Если существует малейшая возможность совершить ошибку при востановлении данных, то она будет совершена", в вашем случае ошибок можно совершить множество. Во-вторых, если у вас попадётся битый сектор, то будут потеряны все бекапы, а не один. В-третьих, я не встречал ещё не одной системы в которой бы простое "посидеть и подумать о давности бекапах" не приводило бы к их сокращению до приделов существующего пространства, если вы исключение, то пойдите и купите ещё 1 диск, это точно надёжнее чем дедубликация.
6. Это самое интересное место. Бекапы научились делать многие, а вот проверять возможность восстановить данные из сделаных бекапов за отведённое время со 100% результатом, единицы.
6. Антон Стеклов (asved.ru) 13.10.16 06:22
(4) Zebar, начать хотя бы с того, что журнал транзакций не содержит никаких "измененных данных", а содержит информацию об изменениях данных, достаточную для повтора этих изменений.
Кроме того, в simple режиме это не работает. А из full схемы явно вытекает log shipping для поддержки актуальной копии на удаленной площадке, про который следовало бы упомянуть.
Кроме того, Вы забыли (или не знали? ;)) про дифференциальный бэкап и про copy_only.
7. Роберт В е р т и н с к и й (v3rter) 13.10.16 08:12
Считаю, что на фоне всеобщей бэкапной безграмотности статьи об архивации надо выкладывать еженедельно, чтобы начинающие админы и пользователи не расслаблялись )

Например: "Резервное копирование 1С средствами MS SQL" http://infostart.ru/public/173494/

У меня в качестве тестирования полного рабочего архива используется его загрузка на тестовую копию на резервном сервере.
Если выгрузка в dt происходит за разумное время, можно использовать ее как дополнительную меру архивации.
В качестве заданий на недельные, месячные, квартальные и годовые архивы я бы использовал "художественное" переименование соответствующий ежедневных, недельных и т.д.
8. Петр Астахов (Zebar) 13.10.16 09:32
(6) Про типы резервного копирования diff и copy_only не забыл. Еще раз - специальная статья по типам резервного копирования будет лучше. Я поставил себе задачу в упрощенном виде рассказать про основные вещи для резервного копирования. И я рассказал о своем опыте, который построен на этих 2 типах.
Насчет full mode для журнала транзакций - у меня это упоминается в неявном виде: "Если максимальный период возможной потери данных небольшой - допустим, полчаса-час, то в базе однозначно требуется включить полную модель восстановления и делать резервные копии журналов с заданной частотой"
Про лог shipping - сталкивался с этим вне пределов 1С, никакого мнения пока не имею, так как у меня нет информации по изменению производительности в схеме быстрый сервер -> медленный сервер


9. Петр Астахов (Zebar) 13.10.16 09:39
(7) Роберт! Насколько я помню, по заявлению самой 1С выгрузка в dt копией не является.
10. Роберт В е р т и н с к и й (v3rter) 13.10.16 10:36
(9) Zebar, разумеется не является. Но удобно, когда есть под рукой для тестовых и вспомогательных целей.
11. Петр Астахов (Zebar) 13.10.16 13:58
(10) Ну, так-то да. Просто мне проще копию восстановить как новую базу, и на сервере 1С ее зарегать.
Заодно и работоспособность копий тестируется.