BTSync как средство бэкапа

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

Специфичный юзкейс, решаемый в данной статье

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

Итак, исходные данные:

• Имя файла и его адрес: известны хотя бы примерно
• Дата создания искомой версии файла: не известна
• Бэкап ежедневный, инкрементальный или равный ему по ресурсоёмкости. Полный и разностный не используются ввиду ограниченности объёмов дискового пространства в хранилище/приемнике бэкапов.

Статья вышла слишком «водяная», так что я спрятал основную воду под спойлеры.

Из-за специфики этого юзкейса восстанавливать файл на дату полного бэкапа (если он не ежедневный, а еженедельный/ежемесячный) не имеет смысла, ибо версия будет скорее всего не актуальной. А из инкрементального — затруднительно, ибо дата создания нужной версии файла и соответствующего инкрементального бэкапа не известна.
Разностный бэкап мог бы решить проблему, но он слишком ресурсоёмкий, и далеко не все могут его себе позволить.

Попытка использования штатного средства резервного копирования/восстановления в Windows server

Но благо мой предшественник побеспокоился о настройке бэкапов на файловом сервере (Windows Server 2003)

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

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

Практически все существующие системы предлагают несколько вариантов бэкапа из списка:

1. Полный — создание точек бэкапа с полной копией всех файлов источника
2. Инкриментальный — создание точек бэкапа с копией всех файлов, которые появились/изменились за время прошедшее с создания предыдущей точки
3. Разностный — создание точек бэкапа с копией всех файлов которые появились/изменились за время прошедшее с создания предыдущей точки полного бэкапа
4. Зеркальный — создание и последующая перезапись единственной точки полного бэкапа. Файлы удалённые из в источника, во время бэкапа удаляются из приемника

Bittorent Sync

NAS

Время шло. В организации появился, а затем остался без дела NAS от QNAP.
И как заявляет производитель: «Работать с TS-221 исключительно просто – достаточно лишь щелкать по нужным иконкам!» Что, кстати, не так далеко от истины. Со временем я нащёлкал таким образом Bittorent Sync ещё 1-ой версии
Благо QNAP позаботились обо мне, написав подробную инструкцию ^[3] по настройке. Правда я не могу сказать что без неё настройка была бы проблемой.

BTSync ^[4], как средство синхронизации файлов нежели резервного копирования, всё же может выступать и в этой роли. Правда реализуется лишь 1 из 4-х описанных выше вариантов — Зеркальный бэкап. Но с одной принципиально важной особенностью: он умеет сохранять удалённые или предшествующие версии изменённых фалов в течении заданного периода времени.

«Роль» системы резервного копирования основывается на следующих функциях/настройках:

• Клиент BTSync должен быть установлен как на источнике так и на приемнике. Это не проблема, ввиду кросплатформенности
  * Вообще-то, источником может выступать сетевая папка, так что клиент может быть установлен на другом ПК
  ** БД (включая настройки) BTSync вроде как хранит отдельно от бинарников, в папке пользователя. Так что теоретически можно запустить 2 независимых интстанса. И сделать источником и приёмником 1 машину
• Резервируемые папки должны синхронизироваться на приемник в режиме READ-ONLY.
  Вы ведь не хотите, что бы изменения синхронизировались и в обратную сторону?
  * Имейте ввиду, что удалённые/изменённые в приемнике файлы больше не будут синхронизироваться, если не поставить галку «Перезаписать любые изменённые файлы». С одной стороны это позволяет аккуратно убирать ненужные для синхронизации файлы, а с другой представляет опасность содержания не-целостных копий. Советую ограничить права на запись/изменение в каталоге приемника для всех кроме пользователя из-под чьего имени работает BTSync.
• На приемнике, в параметрах синхронизируемых папок, должен быть включён режим Сохранять удалённые файлы в архиве.
  В режиме расширенной настройки, параметр sync_trash_ttl определяет количество дней (макс 30) для хранения файлов в папке архива.
• «Расписание» работы в функционал BTSync не входит. Но решается запуском и остановкой приложения через сторонний планировщик (cron и т.п.)
  К сожалению, это не позволяет останавливать синхронизацию по логическому завершению, ибо у синхронизации нет как-такового логического завершения. Но меня устраивает режим запуска BTSync в 18:30 и его принудительного завершения в 7:00. За это время источник и приемнике всегда успевают полностью синхронизироваться.
  

Теперь та же самая просьба сотрудника решается на порядки проще и быстрее. Я просто захожу в приемник в котором структура файлов/папок соответствует вчерашнему (18:30+) состоянию источника. Если же файл был удалён/изменён ранее (в пределах 30 дней) — в путь архива достаточно подставить ".syncArchive" и файлы (а так же их версии) тут как тут.

Недостатки такого подхода

• Нагрузка на CPU — индексация безбожно жрёт CPU при количестве файлов исчисляемом сотнями тысяч. Из-за чего у серверов случается тахикардия. Лично меня это не смущает. Файловый сервер ночью и так простаивает, а бэкап сервер только эту задачу и выполняет, так что ничему не мешает. А бэкапить таким образом ресурс с количеством файлов в несколько миллионов, я даже и пытаться не стал.
• Отсутствие оффлайн-настройки — казалось бы, чрезвычайно юзерфрендли интерфейс должен упрощать настройку до невозможности (так оно и есть). Но сама настройка, может осуществляться только при запущенном btsync приложении (вспоминаем про CPU). Эта проблема частично обходится выключением синхронизации на стороне приемника, и другими костылями… Но я просто не занимаюсь настройкой бэкапов в рабочее время, предпочитая для работы с серверами смещать рабочий день или переносить его на выходной.

А теперь достоинства

• Скорость — думаю скорость BitTorent протокола ни для кого не секрет. У меня нету точных данных, но могу сказать лишь, что попыткам реализовать бэкап через smb|ftp ночи никогда не хватало
• Кросплатформенность — впихнуть можно где угодно и куда угодно. Судя по вики:
  Операционная система: Windows, Linux, OS X, Android, iOS, Windows Phone, FreeBSD и Amazon Kindle Fire
  Аппаратная платформа: x86-64, x86 и ARM
  Языки интерфейса: английский, немецкий, французский, русский, китайский, корейский, японский, испанский, нидерландский, итальянский, бразильский вариант португальского, португальский и турецкий
• Расширяемость/конфигурируемость — благодаря mesh-подходу, приемников и источников может быть несколько. Они могут находиться за NAT. Их можно дублировать и т.д. При этом настройка практически не увеличивает свою сложность с ростом графа источников/приемников. А значит, можно в пару кликов мышкой включить в конфигурацию приёмник вне вашего офиса/ЦОДа, обезопасив себя от нападения инопланетян пожаров и т.п.
• Простота обслуживания — бэкап на стороне приёмника — это точно такая же папка, как и на стороне источника. И ходить в неё можно любым удобным вам методом. Это реально упрощает восстановление отдельных файлов.
• Безопасность — все соединения зашифрованы-перешифрованы. У BitTorent пунктик на эту тему.

Автор: titulusdesiderio

Источник ^[5]