Что такое резервные данные

Урок 25. Резервное копирование (самый важный урок)

Вот мы и добрались до самой важной темы — резервное копирование.

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

Для простоты освоения, я разделил изучение темы на несколько уроков. И этот первый урок ответит на вопрос «что такое резервное копирование» (что такое бэкап) и зачем оно нужно.

В этом же уроке мы узнаем, почему теряются и повреждаются данные и как их обезопасить!

Содержание

Можно воспользоваться ссылками для быстрого перехода:

Отложите все дела и приготовьтесь к приёму полезной информации 🙂

Что такое резервное копирование (бэкап)?

Попробую описать простым языком, что такое резервное копирование:

Резервное копирование или «бэкап» (от английского backup copy) – это создание копии ваших файлов и папок на дополнительном носителе информации (внешнем жестком диске, CD/DVD-диске, флэшке, в облачном хранилище и т.д.).

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

Для простоты часто используют английское слово «backup», которое читается «бэк-ап» и дословно переводится как «запас» (можно перевести как «резервный» или «дублирующий»).

Обратите внимание, в определении я уточнил, что копия должна быть на дополнительном носителе информации, это немаловажный момент. Почему? Давайте разберемся!

Зачем нужно резервное копирование?

Как вы уже догадались, компьютер – это не самое надежное устройство. Данные могут довольно легко повредиться или вообще разрушиться.

Если у вас нет копии, то восстановить важные документы, семейный фотоальбом и видеозаписи может быть очень сложно или совсем невозможно!

Резервное копирование служит спасательным кругом, который поможет восстановить ваши данные!

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

Что такое резервное копирование? Это ваше спасение!

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

Почему теряются данные

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

Давайте рассмотрим самые распространённые причины потери данных:

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

Что нужно копировать?

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

В первую очередь, нуждаются в защите ваши личные файлы:

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

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

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

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

1. Внешний жесткий диск. Устройство довольно надежное, но требует бережного отношения (не любит падений со стола или полки). Кстати, советую периодически контролировать здоровье, как внешнего жесткого диска, так и основного внутреннего.

2. DVD-диски. Имеют другую природу хранения информации, не так боятся падения, но имеют не самую высокую скорость и удобство записи, а надежность зависит от качества дисков («болванок»).

3. Флэшка (USB-флэш-накопитель). Маленькие размеры и простота использования привлекают, но могут ввести в заблуждение на счет надежности, которая далека от идеала. Сразу скажу, что флэшку можно рассматривать лишь как дополнение к основным накопителям для резервного копирования (учтите, что изначально она создана для переноса данных).

4. Облачные хранилища. Сейчас всё чаще говорят об «облаках», действительно, пользоваться такими хранилищами очень удобно, если скорость Интернета достаточно высока. Но есть у этого носителя информации и недостатки, о них мы поговорим в соответствующем уроке (в котором я открою секрет, как избавиться от этих недостатках, не пропустите, подписывайтесь на новости сайта IT-уроки).

Вы спросите «Что же выбрать для бэкапа?». Не поверите, но мой ответ ВСЁ! 🙂

Сколько должно быть копий?

Я уже упомянул, что «должно быть не менее двух копий данных на разных видах носителей», а лучше три-четыре?
Если данные для вас важны, используйте все перечисленные выше носители информации!

Инфографика: три резервные копии

Посмотрите на эту инфографику, и запомните: копии важных данных хранятся в трёх разных местах, на разных видах носителей (например, одна копия на внешнем жестком диске, вторая на DVD-диске, третья на сервере в Интернете).

Эти копии должны храниться отдельно от вашего компьютера (одну копию, в идеале, нужно хранить в другом здании или городе, на случай стихийных бедствий и… первой и пятой причин потери данных, описанных выше).

Как сделать резервное копирование (бэкап)?

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

Любой способ сводится всего к четырем действиям:

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

Как часто делать резервное копирование (бэкап)?

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

Пример 1: вы пишете книгу, каждый день дописываете пять-десять страниц. Резервную копию нужно делать каждый день.

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

Пример 3: вы изредка что-то меняете в своих документах с разной периодичностью. Делаете резервное копирование раз в месяц.

Я рекомендую делать резервную копию не реже раза в месяц.

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

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

А теперь перечитайте еще раз эти правила и запомните их раз и навсегда!

Небольшой опрос

Теперь, когда вы обладаете тайным важным знанием, я хотел бы попросить вас ответить на вопрос:

Благодарю за ответ!

Заключение

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

Обязательно прочитайте продолжение: «Как сделать бэкап (резервное копирование)»

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

Копирование запрещено, но можно делиться ссылками:

Источник

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

Почему нужно защищать данные

Оставлять данные незащищенными, т. е. не делать резервных копий – значит подвергать свой бизнес существенному риску. Исследование организации Disaster Recovery Preparedness Council показывает, что 20 % компаний, у которых случались потери данных от отключения электропитания серверов, понесли потери от 50 тыс. до 5 млн долларов. А 70 % стартапов и небольших компаний были вынуждены прекратить бизнес после масштабных аварий, связанных с потерей данных.

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

Виды резервирования данных

Резервирование данных может быть в виде файлов и в виде образов.

Образы (image) иногда называются «снэпшотами» (от английского snapshot – моментальный снимок), но между этими понятиями есть некоторая разница.

Планы резервирования

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

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

Существуют три основных политики резервирования для всем видов и планов: 3-2-1, GFS и TOH.

3-2-1 предусматривает, что нужно всегда иметь три резервных копии данных на двух типах носителей (например, диск и лента, диск и облако и пр.), причем одна копия должна храниться в отдельном местоположении (например, в другом здании). При использовании облачного варианта в требовании «2» можно обеспечить как другой тип носителя, так и другое местоположение.

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

TOH (Tower of Hanoi) – «Ханойская башня». Название метода происходит от одной из популярных головоломок XIX века. В игре есть три стержня, на один из которых нанизаны восемь колец, причем кольца отличаются размером и лежат меньшее на большем. Задача состоит в том, чтобы перенести пирамиду из восьми колец за наименьшее число ходов на другой стержень. Диски большего размера нельзя размещать на дисках меньшего размера.

Схема перемещения дисков в Ханойской башне

Многие думают, что это означает физическое перемещение дисков из стойки в стойку, но на самом деле нет. Такой план резервирования применяется при ограниченном объеме пространства для резервирования, а также при использовании разных типов носителей для резервных копий. В этом случае, «башни» — это разные носители: диски, ленты, облако. Если использовать только один тип носителей, например, дисков, то при отказе системного ПО и дискового привода теряются все данные. Поэтому, чтобы не держать все яйца в одной корзине, используется метод ТОН. Однако он не очень часто используется на практике вследствие сложности алгоритма.

Решения резервирования

Bare-metal. Cистема резервного копирования ставится непосредственно на «голое железо», а не поверх операционной системы. Поэтому резервирование файлов, в отличие от резервирования образов дисков (вместе с ОС), на Bare-metal не работает: нет метаданных системы и загрузочных меток (bootstrapping). Основное преимущество резервирования образов в том, что оно предоставляет не только возможность восстанавливать файлы на работающей операционной системе, но и возможность полного восстановления на «голом железе», даже когда резервирование делается не на системе, идентичной той, на которой обрабатывались резервируемые данные (приложения, данные и ОС). Резервирование файлов может восстанавливать файлы только в работающей операционной системе, но резервирование образов может восстанавливать файлы как в работающей ОС, так и восстанавливать любые данные на «голое железо». Кроме того, ПО резервирования Bare-metal может преобразовывать физический образ в виртуальный образ, который может быть экспортирован в любую обычную систему виртуализации. При выборе системы резервирования на голом железе возможность выполнения этих функций в конкретном вендорском решении нужно обязательно проверить.

Single-pass. Резервирование Single-pass («один проход») означает, что требуется только одна операция (pass), чтобы захватить и сохранить данные, и только одна операция – чтобы их восстановить. Резервирование Single-pass работает быстрее, чем многопроходные варианты (multi-pass backups) и, следовательно, оно позволяет производить резервирование чаще и за более короткий промежуток времени BW (backup window). Однако при наличии программ резервирования для разного контента (файловое резервирование, резервирование образов и резервирование приложений), даже если они все поддерживают резервирование Single-pass, необходимо будет производить три операции (прохода) резервирования.

Непрерывная защита данных CDP (Continuous data protection), также известное как continuous backup или real-time backup, представляет собой создание резервной копии автоматически при каждом изменении данных. При этом становится возможным восстановление данных при любых авариях в любой момент времени, при этом доступна актуальная копия данных, а не те, что были несколько минут или часов назад. Однако это метод довольно затратный и используется только в исключительных случаях.

Удаленная репликация данных (Remote Replication) поддерживает две или более копий данных на двух или более сайтах для предотвращения потери информации в случае аварий.

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

Удаленная репликация данных

Выбор ПО и среды резервирования (Backup Media)

Чтобы выбрать носитель (среду) для резервирования, сначала нужно определить, какая емкость для этого понадобится (хотя бы примерно). Это зависит, прежде всего, от того, сколько копий нужно хранить, за какой период времени (это часто определено в регулировании для той или иной прикладной области), а также от скорости роста объема данных на предприятии, где создается система резервирования данных. Приблизительно можно сказать, что нужно умножить текущий объем данных в 3–5 раз. Однако нужно следить за скоростью роста данных, чтобы вовремя внести коррективы.

После того, как получен требуемый объем системы хранения для резервирования, необходимо выбрать среду (носитель данных) этой системы. Основных типов сред резервирования – три: дисковые СХД, ленточные библиотеки и облако. У каждого из них есть достоинства и недостатки.

Диски: быстро работают, но они относительно дорогие, хотя в последнее время наблюдается постоянное снижение цен на твердотельные диски SSD.

Ленты: обладают большими объемами, также довольно быстрые, но сложные в нахождении нужных данных и в управлении. Кроме того, ленты гораздо менее надежны, чем диски, потому что их легко повредить при обслуживании и перемещении.

Кассеты с лентой для ленточного накопителя

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

Облако. Облако (Cloud) великолепно подходит как резервная система для удаленных офисов компаний и небольших серверов. Для такого сценария, особенно в случае выбора политики резервирования «3-2-1», облако – оптимальный выбор. Недостатком облака являются задержки и зависимость от облачного провайдера, а также надежность канала доступа к нему. Кроме того, немаловажным фактором является безопасность – очень часто предприятия просто боятся выпускать конфиденциальные данные за пределы корпоративного файрволла.

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

Железо:

Ленты:

Восстановление данных

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

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

Катастрофоустойчивость

Катастрофоустойчивость (DR, Disaster Recovery) – это восстановление данных при стихийных бедствиях. Это довольно важная составляющая серьезных промышленных СХД, хотя и достаточно затратная. Но эти затраты необходимо нести, чтобы не потерять в одночасье то, что «нажито непосильным трудом». Технологии защиты данных (Snapshot, Remote Replication, CDP) хороши до тех пор, пока в населенном пункте, где расположена СХД, не произошло какое-либо стихийное бедствие: цунами, наводнение, землетрясение или что еще похуже. Удаленная репликация данных в политике «3-2-1» подразумевает, что реплицирующая СХД находится в том же населенном пункте, что и основная система, или, как минимум, поблизости. Что, например, при цунами не спасает.

Технология Disaster Recovery предполагает, что центр резервирования, используемый для восстановления данных при стихийных бедствиях, располагается на значительном удалении от места основного ЦОД и взаимодействует с ним по высокоскоростной сети передачи данных, наложенной на транспортную сеть, чаще всего оптическую.

Источник

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

Эта статья — часть цикла о построении 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, который, правда, давно не обновлялся.

Источник