что такое бэкап сервера

Как сделать бэкап и для чего он нужен

реклама

Среди айтишников ходит присказка-поговорка: «есть два типа людей – кто еще не делает бэкапы, и кто уже делает». И действительно, один раз потеряв ценную для себя информацию, и с трудом и большими денежными затратами восстановив ее, или вообще не сумев восстановить, вряд ли какой-то здравомыслящий человек захочет столкнуться с подобной ситуацией еще раз. В этой статье я расскажу о бэкапах (резервных копиях) данных – что это такое, зачем они нужны, как и где их делать.

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

Что такое бэкап простыми словами?

Бэкап – это резервная копия каких-либо данных. Например, в вашем компьютере установлены 3 накопителя: SSD и два жестких диска – HDD 1 и HDD 2. На HDD 1 вы храните ценные для вас семейные фотографии, и вдруг он выходит из строя, унося с собой всю имеющуюся на нем информацию. Вы пробуете программы для восстановления данных с поврежденных «винчестеров», но ничего не помогает. Остается только одно – идти в специализированный сервис и отдавать кругленькую сумму. И то не факт, что помогут. А вот если бы эти фотографии были не в единственном экземпляре и хранились где-нибудь еще…

Как сделать бэкап?

реклама

Сделать резервную копию каких-либо файлов очень просто: их нужно скопировать на другой физический накопитель. Подчеркну: именно на другой физический накопитель, а не на другой «локальный диск». Физический накопитель (SSD или жесткий диск) может состоять из нескольких разделов. Простой пример из жизни: физический накопитель – это ящик для столовых приборов, а локальные диски – это разные отсеки; один для ножей, один для вилок, один для ложек и так далее. То есть, если у вас HDD 1 разбит на разделы D и E, а HDD 2 на разделы F и G, то недостаточно скопировать фотографии из раздела D в раздел E – необходимо «забэкапить» их в раздел F или G. Но находясь даже в нескольких экземплярах на одном компьютере или в одной квартире, данные все равно могут потеряться – например, в случае чрезвычайных обстоятельств вроде пожара. Вот простые правила, которые помогут этого избежать.

Главные правила резервного копирования

Правило первое: для действительно важных данных должно существовать как минимум три бэкапа, физически находящихся в разных местах, причем парочка из них – на удаленных серверах. В случае пожара, затопления и других форс-мажорных обстоятельств вы легко можете лишиться всех электронных устройств, находящихся в одной квартире, поэтому бэкапов «по месту жительства» недостаточно. Но почему я предлагаю именно два удаленных сервера? Да потому что, если такой сервер один, с ним тоже может случиться форс-мажор (сгорел дата-центр, закрылась компания, случайно стерли данные), а вы об этом узнаете только если потеряете «оригинальные» данные и их копию по месту жительства.

реклама

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

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

Правило третье: если речь идет о домашнем ПК, делайте резервные копии только действительно важных данных. Нет никакой надобности бэкапить любимые игры или сериалы – если полетит SSD/жесткий диск, их всегда можно скачать заново. А вот уникальные и имеющиеся только у вас данные, такие, как сохраненки для игр, уже вполне можно бэкапить, если вы заядлый геймер. Но чаще всего в случае домашних бэкапов сохраняются копии личных/семейных фотографий и видео, а также заметок.

реклама

Выбор этих важных данных должен быть индивидуальным. Ценные для вас фото, скриншоты заметки, и тому подобное стоит бэкапить всегда (только не забывайте все это шифровать!), а дальше – как говорится, кто на что горазд. Если вы просидели много сотен часов в Скайриме, то стоит сделать резервную копию нескольких сохранений с разных этапов игры, если вы играете в покер на деньги – бэкапьте базу данных с информацией на оппонентов, если храните криптовалюту – бэкапьте кошельки или данные для доступа к ним.

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

Как защитить резервную копию данных на удаленном сервере при помощи шифрования?

Любые чувствительные данные вроде бэкапов личных заметок, фото и криптокошельков, следует защищать при помощи шифрования. Рекомендую использовать VeraCrypt – программу с открытым исходным кодом, которая в свое время стартовала как форк TrueCrypt. В настоящий момент она считается одним из самых надежных бесплатных решений для шифрования и используется журналистами, активистами и лицами, работающими с чувствительной информацией, по всему миру.

Выберите «Тома» – «Создать новый том», далее – «Создать зашифрованный файловый контейнер» – «Обычный том». Подойдет AES с алгоритмом хеширования SHA-512. После этого укажите максимальный размер тома – он должен быть таким, чтобы туда влезли все ваши файлы, резервную копию которых вы хотите создать. Введите подходящий пароль и подтвердите, что собираетесь хранить в контейнере файлы размером более 4 ГБ. Дальше следуйте указаниям программы. Жмите «разметить», а по окончанию шифрования монтируйте созданный контейнер и переносите туда нужные файлы, после чего размонтируйте.

Все, файлы зашифрованы, можно заливать том в облако/на удаленное хранилище! Если хотите, можете перед этим еще и заархивировать контейнер с паролем, чтобы уменьшить его размер, но это необязательно. Главное, не забудьте разархивировать/размонтировать бэкап и проверить его работоспособность перед тем, как начать загрузку, после же загрузки скачайте его и повторите процедуру. Это может занять немало времени, но, поскольку резервные копии домашних данных создаются нечасто – ничего страшного.

Заключение

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

Источник

Система резервного копирования

Эта статья — часть цикла о построении NAS, и написана под конкретный вид системы.

Резервное копирование — вторая основная задача, которую я хотел решить, используя NAS, после системы управления репозиториями.

Решение её затянулось.

Про данную тему уже написана масса статей и даже несколько книг, а в спорах об этом сломано много копий.

Ниже — попытка разобраться в этой куче материала, уложить его в голове и построить небольшую систему относительно грамотно.

Система резервного копирования (СРК) определяется:

Регулярный процесс резервного копирования, делится на следующие основные части:

Точки сопряжения системы с платформой NAS:

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

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

Принципы резервного копирования

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

На этих принципах строятся политика и регламент.

Вот несколько основных:

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

Политика резервного копирования

Очевидно, что цель всякого резервного копирования — понижение затрат от незапланированного уничтожения данных в нештатных ситуациях.

Достигается эта путём дублирования ценных данных с рабочих машин в сторонние хранилища.

Задачи резервного копирования

Следующие задачи определяются из целей резервного копирования:

Требования к системе

Далее в списке, как функциональные, так и нефункциональные требования вперемешку:

Состав резервируемых ресурсов

В моём случае он достаточно типичен:

Состав угроз

Это то, где, что и от чего следует защитить и каким образом.

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

Дополнительные условия политики

Их желательно учесть:

Последний пункт политики я не учитываю, потому что обычно мой рабочий процесс не меняется, и достаточно следить за объёмом некоторое время, только для первоначальной настройки.
Опытным путём было выяснено, что схема «месяц, неделя, день, час» вполне меня устраивает.
Для более крупных систем, возможно потребуется менять частоту бэкапов динамически для каждой системы.

Регламент резервного копирования

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

Задачи регламента

Пример регламента

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

РЕГЛАМЕНТ РЕЗЕРВНОГО КОПИРОВАНИЯ ДАННЫХ В ТЕРРИТОРИАЛЬНЫХ ПОДРАЗДЕЛЕНИЯХ РОСРЕЕСТРА

Оглавление

1 Общие положения

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

Настоящий Регламент разработан с целью:

Под резервным копированием информации понимается создание полных копий производственных БД Управления, для быстрого восстановления работоспособности информационной системы ведения ЕГРП АИС «Юстиция», в случае возникновения аварийной ситуации, повлекшей за собой повреждение или утрату данных.

Резервному копированию подлежат все производственные БД всех территориальных отделов Управления.

Машинным носителям информации, содержащим резервную копию, присваивается гриф конфиденциальности по наивысшему грифу содержащихся на них сведений.

Резервные копии хранятся вне пределов серверного помещения, доступ к резервным копиям ограничен. Список лиц, имеющих доступ к данным, формируется на основании письменной Заявки руководителя подразделения информационных технологий (ИТ), согласованной с руководителем подразделения информационной безопасности (ИБ). Изменение прав доступа к резервируемым техническим средствам, массивам и носителям информации производится на основании Заявки руководителя подразделения ИТ, согласованной с руководителем подразделения ИБ. О выявленных попытках несанкционированного доступа к резервируемой информации и аппаратным средствам, а также иных нарушениях ИБ, произошедших в процессе резервного копирования, сообщается в подразделение ИБ служебной запиской в течение рабочего дня после обнаружения указанного события.

2 Порядок резервного копирования

Резервное копирование производится штатными средствами СУБД Oracle. Резервное копирование может производится:

Резервное копирование БД производится не реже 1 раза в сутки. Срок хранения резервной копии БД не менее 1 месяца.

Стратегия резервного копирования должна гарантировать синхронное восстановление данных, расположенных в разных схемах БД. Например, схема ХЭД (хранилище электронных документов), должна копироваться одновременно со схемой АИС Юстиция.

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

3 Контроль результатов

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

В случае обнаружения ошибки лицо, ответственное за контроль результатов, сообщает о ней в службу технической поддержки разработчика не позднее 11 часов текущего рабочего дня.

4 Нормативно-правовое обеспечение

Для организации процесса резервного копирования необходимо:

5 Ротация носителей резервной копии

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

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

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

6 Восстановление информации из резервной копии

В случае необходимости восстановление данных из резервных копий производится ответственным работником подразделения ИТ, указанным в Приложении N 2.

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

Восстановление системного программного обеспечения и программного обеспечения общего назначения производится с их носителей в соответствии с инструкциями производителя.

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

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

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

7 Приложение 1

Пример запуска утилиты экспорта Oracle из командной строки:

exp userid=JUST_USER/PASSWORD@SERVER owner=(JUST_USER,HED_USER) direct=Y consistent=Y statistics=NONE compress=N file=C:\BACKUP.DMP log=C:\BACKUP.LOG

owner=(JUST_USER,HED_USER) – перечень копируемых схем, в данном примере одновременно экспортируются схема АИС Юстиция и схема ХЭД;

file=C:\BACKUP.DMP – путь и имя создаваемого файла экспорта;

log=C:\BACKUP.LOG – путь и имя создаваемого файла лога экспорта.

8 Приложение 2. Перечень лиц, ответственных за резервное копирование

Здесь вы найдёте ещё один пример с небольшим описанием.

Процедура резервирования

Состав резервируемых данных:

Процедура восстановления

Общая процедура восстановления после сбоя для рабочих машин:

Следует заметить, что до третьего пункта я ни разу за время использования Debian не доходил (начиная со Squeeze от 2011 года), и подобная ситуация у меня была лишь когда я использовал Slackware на ReiserFS более десяти лет назад.

Общая процедура восстановления после сбоя для роутера:

Mikrotik вполне меня устраивает, а настройки в RouterOS совместимы.

Процедура проверки работоспособности

Предлагается использовать для проверки работоспособности виртуальную машину, запущенную на стационарном компьютере.

Условия хранения резервных копий и требования к носителям

Решения для резервного копирования

Пришло время рассмотреть программное обеспечение, которое может быть использовано для резервного копирования.

Требования к ПО

При выборе я руководствовался следующими требованиями:

Выбор ПО

Под спойлером ниже рассмотрены несколько возможных систем для резервного копирования.
Ещё больше вы можете найти здесь, и здесь.

Решения на базе unix-утилит

Решения на основе rsync, tar, rdiff-backup, etc. не рассматриваются по причине большого количества работы, которую потребуется выполнить, и отсутствия необходимого WEB-интерфейса.

Bareos

BareOS (Backup Archiving Recovery Open Sourced) — форк Bacula с 2010 года.

BackupPC

Безагентная система резервного копирования.

Плюсы и возможности:

UrBackup

Клиент-серверная система резервного копирования с агентом.

Плюсы и возможности:

Restic

Инструмент для резервного копирования и восстановления с консольным интерфейсом.

Плюсы и возможности:

BorgBackup

Дедуплицирующая программа для резервного копирования.

Плюсы и возможности:

Lsyncd

Демон, выполняющий резервирование изменяемых файлов через rsync.

Плюсы и возможности:

Box Backup

Автоматическая онлайновая система с открытым исходным кодом.
Вот более подробное описание.

Плюсы и возможности:

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

Я не буду повторяться и далее покажу лишь несколько специфичных моментов.

Настройка сервера UrBackup

Если файловая система под бэкапы ещё не создана, её надо создать:

Снэпшоты не требуются, а вот сжатие лучше включить, следуя части руководства UrBackup про ZFS бэкэнд.

На своё усмотрение, при наличии достаточного количества памяти возможно подключить дедупликацию на данной файловой системе:

Теперь возможно поднять сервер UrBackup в контейнере:

Конфигурационный файл docker-compose приведён ниже.
Дальнейшая настройка производится из Web-интерфейса сервера и подробно описана в Руководстве администратора.

Следующее, что требуется сделать после запуска сервера:

Основные настройки сервера:

LDAP настроить мне не удалось, но это не особенно критично: сервер имеет только одного администратора, сами же агенты имеют доступ только к своим данным.

Запрос группы и класса был следующий:

Если у кого-то получится, жду рекомендаций в комментариях.

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

Обратите внимание, что тут задаётся имя сервера, которое будет прописано в архиве с преднастроенным агентом.

Порты, используемые UrBackup:

Соответственно, порт 55415 нужно пробросить на роутере, а порты 35621, 35622, 35623 отобразить на соответствующие порты хоста и разрешить в брандмауэре.

Установка агента

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

Есть несколько вариантов поставки агента:

Агент в UrBackup преднастроенный, т.е. скачивать его надо с вашего сервера, и доступен он будет доступен на странице вашего сервера после добавления клиента:

Именно отсюда его и надо качать.

Вот пример установки из shell архива:

После установки и запуска агент должен выдать нечто подобное:

В настройках для NAS клиента надо выставить отдельные параметры, задав следующие каталоги:

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

После того, как всё готово и установлено, выбрав пункт, «Полный файловый бэкап», будет видно, что индексирование пошло:

На клиенте оно должно выглядеть примерно так:

Проблемы

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

Также может появляться следующая ошибка:

Решается большинство проблем корректной установкой настроек сервера и переустановкой клиента на заново скачанный.

Перед этим желательно остановить агент и удалить настройки:

Сразу после того, как агент был установлен, правильная конфигурация выглядит подобным образом:

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

Запуск полного резервного копирования после обновления

В Debian, как я уже писал, это решается следующим простым хуком в /etc/apt/apt.conf.d/80full-backup :

Резервная копия роутера

К статьям о NAS, это уже не относится. Лишь замечу, что резервное копирование может быть выполнено через утилиту mtbackup по SSH, которая запускается на NAS.
Небольшая обвязка на Python может заниматься ротацией бэкапов, а сам каталог, в который они сохраняются, резервироваться штатно через UrBakup, либо в облако.

Проверка восстановления

Последний, в данный момент не сделан: я пока обкатываю работу бэкапа и убираю оттуда лишнее. Так что, это задача на будущее.

Принципиально он является скриптом, который делает следующее:

Задача достаточно тривиальная, но если кому-то интересно, могу потом к ней вернуться.

Облачные сервисы для резервирования

Статья про резервное копирование получилась достаточно объёмной.
А как мне видно из практики, объёмные и подробные статьи тут мало кому интересны, да и усилия от публикации на Хабре себя не оправдывают.
Поэтому о репликации в облако я как-нибудь напишу отдельно, а пока могу лишь заметить, что в качестве облачного хранилища достаточно интересно Storj.

Литература

Подробнее о принципах и рекомендациях, которые возможно применить в процессе разработки системы, возможно почитать в следующих источниках:

Также, в книгах и больших работах:

В большинстве книг описаны серьёзные инфраструктуры.

Следует читать и применять изложенное в них, если вам нужно или очень хочется посчитать и обосновать RTO, RPA, RPO. Впрочем, если вы это делаете, скорее всего вы и так занимаетесь резервированием крупных систем, и моя статья для вас бесполезна.

Кое-что вы можете также найти в разделе литературы о NAS, который, правда, давно не обновлялся.

Источник