Ввeдeниe
Пoжaлуй, с пeрвoгo дня, кoгдa я пoзнaкoмился с NAS-aми Synology, я нe устaвaл пoвтoрять, чтo этим устрoйствaм кaтaстрoфичeски нe xвaтaeт функции цeнтрaлизoвaннoгo бэкaпa, кoгдa инициaтoрoм рeзeрвнoгo кoпирoвaния являeтся сaм NAS, кoгдa oн сaм зaxoдит нa клиeнтскиe мaшины и бэкaпит с ниx тo, чтo нужнo. Цeнтрaлизoвaннo, по расписанию, без установки на клиентские машины дополнительного ПО. Эта функция, именуемая в Linux-среде Rsync-насосом, способна значительно облегчить настройку резервного копирования парка Linux-серверов.
В чем преимущество централизованного бэкапа?
Прежде всего, в том, что вся настройка резервного копирования ведется через Web-интерфейс NAS-а. Вам не нужно устанавливать дополнительное программное обеспечение на машины, с которых осуществляется копирование. В случае, если используется протокол передачи RSync или SSH, вам не нужно работать с командной строкой на клиентской машине. И поскольку SSH — нативный протокол операционной системы Linux, а Rsync доступен на всех дистрибутивах, то работа задачи резервного копирования не зависит от дистрибутива — вы одинаково легко настроите задачи бэкапа с десятка Ubuntu-машин, нескольких CentOS серверов и нескольких Windows-станций.
Второе преимущество — это легкость восстановления данных, из того же самого Web-интерфейса NAS-а Synology. То есть, если пострадали файлы, осуществляющие доступ к графической оболочке Linux-машины, вы можете восстановиться из бэкапа, даже не заходя на искомый Linux-клиент.
Разумеется, чем больше и чем разнороднее парк компьютеров и серверов организации, которые необходимо бэкапить, тем ощутимее будут удобства централизованного бэкапа с NAS-а.
В чем недостатки централизованного бэкапа?
Единственный существенный недостаток такого подхода состоит в том, что NAS-у для доступа к клиентским машинам, нужны логин и пароль. Как правило, для бэкапа создают отдельную, усеченную в правах, клиентскую запись, но и это может кого-то не устраивать, если политика конфиденциальности в компании просто параноидальная.
Централизованное резервное копирование производится последовательно — одна задача с одной машины за одно время. И если у вас установлены 100 машин, то пока не будет зарезервирована первая, ко второй NAS не приступит. Таким образом, время между резервными копиями может быть чересчур большим, если с каждого сервера вы бэкапите большое количество данных. Даже при инкрементальном копировании, NAS все равно будет проверять каждый файл в заданной папке на предмет изменений. Так что будьте готовы к тому, что интервал между резервными копиями может составлять не день-два, как вы хотели бы, а неделю.
Поддерживаемые протоколы
Для работы с Windows-машинами, поддерживается только протокол Samba, для Linux -протокол Rsync через модуль или через подключение по SSH с с возможностью выбора порта.
Инкрементальные бэкапы и Smart Recycle
Разумеется, в соответствии с требованиями, предъявляемыми современными пользователями, резервные копии должны быть инкрементальными. То есть, в резерве должна храниться история изменения файлов за длительный период, допустим за полгода, и пользователь должен иметь возможность прокрутить временную ленту назад, найти нужный файл, допустим, в версии позапрошлого месяца и восстановить его в исходное место.
Synology Active Backup for Server имеет похожую возможность. Вам предоставляется не только статистика по сделанным резервным копиям, но и возможность восстанавливаться с того момента, когда вам нужно. Правда, восстанавливается вся папка сразу, отдельный файл или отдельный каталог выбрать нельзя. А технология Smart Recycle экономит место, занимаемое различными версиями одного и того же бэкапа, увеличивая шаг во времени между старыми копиями.
Установка и настройка
Synology Active Backup for Server устанавливается как типичный пакет расширения через «цент пакетов» в DSM вашего NAS-а. Еще раз хочется заметить, что пакет доступен только для NAS-ов, ориентированных на бизнес-использование. На моделях для домашнего использования пакет недоступен. Никакой настройки не требуется — все готово и работает сразу после установки.
Стартовая страница интерфейса показывает состояние задач резервирования и занятое резервными копиями дисковое пространство.
В левом списке выбираем «Резервирование Linux» и создаем новую задачу. На выбор нам предоставляются три типа резервных копий — несколько версий, зеркальное отображение и инкрементный бэкап.
Самая полезная, но и больше всего занимающая место — это «несколько версий». Это некий аналог Apple Time Machine — система хранит заданное количество резервных копий за последнее время, и вы можете восстановить данные из любой из этих копий. Выбрав, что и куда бэкапить, вы можете настроить количество хранимых версий.
Для экономии дискового пространства, рекомендуем включить функцию Smart Recycle — она хранит ежечасные копии за последние 24 часа, ежедневные за последний месяц и еженедельные за период старше 1 месяца. Причем, частота сохранения резервных копий зависит от их количества. Сделайте 12 копий — и получите ежедневные бэкапы, сделайте 256 — и получите всю прелесть: ежечасные, ежедневные, еженедельные. Для наглядности, здесь же на диаграмме показано, какое количество копий и за какой период будут сохраняться.
Пару слов о восстановлении из бэкапа. Как уже было сказано, восстанавливать можно только целиком зарезервированную папку, за указанный день. Интерфейс восстановления позволяет вам на временной шкале выбрать дату, «когда все было хорошо», и каталог, куда именно произвести восстановление — туда откуда делалась резервная копия, или в другое место. Процесс восстановления занимает чуть больше времени, чем процесс бэкапа, и к этому нужно быть готовым. Очень надеюсь, что в следующих версиях программного пакета, появится возможность выбирать, что именно из бэкапа восстанавливать, так как это существенно ускорит процесс.
Тестирование в реальных условиях
Пожалуй, единственное, что имеет смысл измерить при тестировании — это скорость резервного копирования. Дело в том, что механизм бэкапа через Rsync выглядит следующим образом: сначала клиентская машина обращается к серверу, с которого надо резервировать данные, затем обходит все каталоги, которые надо зарезервировать, и только потом приступает, собственно, к процессу передачи данных. Из-за этого, процесс резервирования будет длиться тем дольше, чем больше файлов и каталогов вы бэкапите.
К слову, механизм типичного резервирования выглядит иначе. Когда вы запускаете бэкап на самом сервере, ему не надо через сетевой протокол проверять каждый каталог и каждый файл — он практически сразу начинает архивирование каталогов, обращаясь к файловой системе, и уже затем передает архив на внешний носитель, или куда там выбрано. Поэтому, с точки зрения затраты ресурсов, можно сказать следующее: Active Backup for Server от Synology будет давать небольшую нагрузку на процессор Linux-сервера и сетевой канал, но будет осуществлять резервирование тем дольше, чем больше файлов и каталогов вы бэкапите. Локальный бэкап на сервере потребует больших ресурсов процессора и дисковой подсистемы, но осуществит резервирование значительно быстрее. Более того, динамичные файлы, такие как например, базы данных, ни тем ни другим способом зарезервировать не удастся.
Для тестирования использовалась следующая конфигурация:
- Synology DS1511+, 5×1TB HDD 7200k SATA RAID 5
- Сервер:
- Core i7 860, 8С, 2.8 GHz
- 16 Gb RAM
- LSI Megaraid 9240–8i
- 2xHDD Hitachi Ultrastar 15k600 600gb SAS RAID 1
- Ubuntu 15.10
- Тестовый каталог — 35588 папок, 188854 файлов объемом 38.8 Гб
В первом случае мы бэкапили каталог через Synology Active Backup for Server. Во втором случае — через команду TAR — в локальный архив на сервере в режиме Background, а затем через Rsync — передачу этого архива на тот же NAS.
Время резервирования:
- Synology Active Backup for Server — 7 часов 20 минут 8 секунд, загрузка процессора — 10%, загрузка дисковой системы — 5%
- Архивирование TAR на сервере с последующей загрузкой на NAS — 5 часов 10 минут, загрузка процессора — 36%, загрузка дисковой системы — 10%.
Выводы
Такое решение, как Synology Active Backup for Server, лично я ждал, без преувеличения, много лет. Казалось бы, как просто было бы взять, да и бэкапить Linux-серверы централизованно, удаленно. Для тех, кому лень изучить синтаксис Rsync и TAR, такое решение — просто находка. Особенно полезен интерфейс с выбором различных версий резервных копий. Без преувеличения, это огромный плюс, когда на рабочей машине что-то полетело и надо максимально быстро все вернуть в исходное состояние.
Однако, стоит понимать, что при больших объемах данных, удаленный бэкап через SSH и Rsync может занимать часы и даже сутки. В этом случае у вас будет сдвигаться расписание бэкапов, а ежедневные или ежечасные бэкапы могут просто не создаваться. А динамические файлы, такие как файлы баз данных, вообще не могут быть скопированы без остановки использующего их приложения.
В сегодняшних реалиях я рекомендую вам использовать для бэкапа средства самого сервера — резервирование встроено в любое мало-мальски серьезное приложение. И уж если нет возможности установить программу для архивирования данных, лучше всего создавать локальную копию резерва на самом сервере, а такое решение как Synology Active Backup for Server использовать для вытяжки готовых архивов бэкапа с сервера на NAS.
LIKE OFF
28/05.2017
