Бэкапы - начало.

Введение

В этой статье поговорим о резервном копировании вообще, как о принципе защиты информации. Так же поговорим про бэкап конкретных сущностей - файлы, 1с, базы данных, виртуальные машины. Каждая из этих сущностей имеет свою специфику, поэтому я применяю к ним немного разные подходы.

Вообще есть такой парень Питер Крог, он фотограф, и в свое время был настолько сильно озадачен сохранностью своего портфолио, что очень много времени посвятил мыслям о резервном копировании своих фотографий. В книге «Управление цифровыми активами для фотографов» он рассказывает про принцип резервного копирования 3-2-1, вот что он означает:

• Всегда имей 3 резервные копии данных;
• Держи их в 2х разных физических форматах хранения (например hdd + dvd);
• Причем 1 копия должна храниться в другом географическом месте (например отправлять на облачный диск).

В общем и целом я с ним согласен, но кто из нас сегодня будет заморачиваться и ежедневно писать бэкапы на DVD болванки? Поэтому возьмем мудрые советы Питера и пропустим их через призму личного опыта и сегодняшних реалий. Добавим несколько дополнительных принципов, которые на мой взгляд очень уместны:

• Используй PULL принцип - НЕ делай бэкап средствами той ОС, на которой лежит оригинал информации. Оригинал ничего не должен знать о том делаются ли бэкапы, куда, как часто и так далее. Особенно плохо когда оригинал взломан хакером или шифровальщиком. Всегда есть риск, что будут обнаружены скрипты или программы резервного копирования, из них будет получена информация о том где лежат бэкапы и как туда попасть;
• Само по себе наличие бэкапа еще ничего не значит. Нужно быть уверенным на 100%, что бэкап создался правильно и ты сможешь из него восстановиться. Для этого нужно периодически проверять бэкапы, пробовать достать из них информацию.

Угрозы и меры противодействия

Какие, собственно, бывают угрозы сохранности данных и какие бывают методы противодействия этим угрозам?

Речь идет только про сохранность, вопрос правомерности доступа, настройка безопасности в этом материале не рассматривается.

Проблема	Противодействие	Комментарий
Выход оборудования из строя.	Использование RAID массивов, ведомых серверов БД, репликация.	Защитит только от поломки оборудования. Если испортить информацию - она автоматически испортится на репликах, ведомых серверах, всем RAID массиве. Решает вопрос быстрого восстановления рабочего процесса. Или восстановление проходит вообще прозрачно для пользователей.
Непредумышленная порча информации. Пользователь нечаянно удалил файлик или запорол базу 1с.	Теневое копирование. Резервное копирование.	Восстановиться из теневой копии очень просто и быстро. Можно настроить гибко расписание. Подходит для "рутинного" восстановления при "рутинных" ошибках пользователей. Резервное копирование решает вопрос. Но как часто его проводить - размышляем отдельно под каждую отдельную ситуацию.
Умышленная порча информации, вирусы, шифровальщики, обиженные сотрудники.	Резервное копирование.	Эта мера противодействия в полной мере решает вопрос сохранности информации. Остаются частности - как часто делать бекап, какое кол-во бэкапов хранить, сколько и где копий бэкапов держать. Тут все очень индивидуально, каждый отдельный случай анализируется и выбирается оптимальное решение.
Техногенный фактор.	Резервное копирование на удаленный сервер.	Лично видел потопы в серверных комнатах, последствия пожара в офисе. Ну и так далее можно нафантазировать подобных угроз вплоть до падения астероида на офисное здание. Поэтому вынести бэкап куда то подальше от офиса вполне уместно.

Бэкап файлов

Как показала практика, для небольших компаний вполне достаточно делать бэкап 1 раз в сутки + использовать теневое копирование с настройками по-умолчанию (2 копии в день в 7:00 и 12:00).

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

Резервные копии делаем как минимум на соседний диск от диска с оригиналом. Еще лучше, если есть отдельный бэкап-сервер, тогда бэкапы держим и на этом бэкап-сервере, и на оригинальном сервере на отдельном жестком диске. И совсем хорошо, если есть облако с достаточным количеством места или есть удаленный филиал компании, тогда очень уместно дублировать бэкапы туда.

Таким образом мы, конечно, не полностью соблюдаем принцип 3-2-1, как завещал Питер, но получаем вполне себе отказоустойчивую и надежную систему резервирования информации.

Разберем основные подходы копирования файлов, их всего 3, они справедливы для любого ПО.

• Полное копирование. Самое простое - каждый раз создавать точную копию оригинальных данных. Самое прожорливое - копирует даже неизмененные файлы, нужно много места. Легко восстановиться - просто открыл копию за нужно число и забрал из нее файлы.
• Дифференциальное копирование. Немного посложнее и по-экономнее, но все равно может хранить одни и те же версии данных в нескольких копиях. Сначала делается ПОЛНАЯ КОПИЯ оригинальных данных (например каждое первое число месяца). Далее делаются дифференциальные копии - копируются только те данные, которые отличаются от данных в ПОЛНОЙ КОПИИ. Для восстановления нужно сначала восстановить данные из ПОЛНОЙ КОПИИ, а потом сверху восстановить данные из дифференциальной копии за нужное число. Ключевой момент тут - дата создание полной копии, который и определяет глубину архивирования.
• Инкрементное копирование. Самое экономное по занимаему месту, но трудозатратное по восстановлению. Точно так же вначале создается полная копия данных, затем делаются инкрементные копии - копируются только те данные, которые изменились с момента выполнения прошлого резервного копирования (полного или инкрементного). Чтобы восстановиться из такого бэкапа нужно проделать сложную процедуру - сначала восстановиться из полной копии, потом сверху последовательно восстанавливать данные из каждого следующего инкремента до тех пор, пока не восстановим инкремент нужной нам даты.

Есть еще гибридный подход "обратный инкремент", которым я в основном и пользуюсь. С одной стороны он вбирает в себя лучшее от инкрементного и дифференциального копирования, с другой стороны у него появляются дополнительные операции чтения-записи, что делает его немного более ресурсоемким. Подробно про этот способ, его преимущества и недостатки можно почитать тут, я же кратко изложу алгоритм его работы:

1. При каждом выполнении архивации поддерживается ПОЛНАЯ КОПИЯ оригинальных данных - зеркало;
2. В случае, если в ОРИГИНАЛЕ файл новее чем в ЗЕРКАЛЕ, то файл из зеркала переносится в инкремент, а на его место записывается свежая версия из ОРИГИНАЛА;
3. Удаляются старые инкременты, остается только то количество, которое нам нужно.

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

По этому принципу написан скрипт, вынесен в отдельную статью: обратный инкремент на Rsync.

Резервное копирование баз данных

В повседневной работе мне приходится сталкиваться в основном с 1с, БД которой обычно хранится в файловом виде, БД POSTGRESQL или в БД MSSQLSERVER

Помимо 1с наиболее часто возникает необходимость бэкапить БД из MySQL или MariaDB (которая по сути MySQL и есть)

Итак, коротко поговорим о резевном копировании этих БД

• 1с - файловый вариант БД. Тут все просто - копируем папочки с базами. САМОЕ ГЛАВНОЕ - чтобы в момент копирования в базе никто не сидел, в противном случае 99% бэкап получится кривой. Самые оптимальные инструменты это Effector Saver (вполне хватит официальной бесплатной версии) или скрипт на Rsync.
• 1с - POSTGRESQL. Первое что приходит на ум - это выгружать в DT, Но это не самый лучший вариант - сама 1с говорит, что DT нельзя использовать как инструмент резервного копирования. В данном случае лучший способ бэкапить 1с - это выгрузка базы напрямую из сервера БД минуя надстройку с 1с. Очень желательно обеспечить условие, чтобы в момент снятия дампа в базе никто не сидел. Если бэкап делаешь в среде Windows, то используй EffectorSaver. Он умеет работать именно с БД постгреса, только в систему потребуется установить клиентские утилиты postgresql. Ну а если бэкапишь в среде linux - я под себя написал вот такой скрипт.
• 1с - MSSQLSERVER. В процессе написания

Для бэкапа MySQL или MariaDB написан вот такой скрипт - в процессе офрмления статьи.