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

в 4:42, , рубрики: bittorent, BitTorrent Sync, btsync, бэкап, децентрализованные сети, ит-инфраструктура, ненормальные решения, необычные решения, резервное копирование, системное администрирование, хранение данных

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

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

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

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

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


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

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

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

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

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

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

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

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

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

И то ли я смотрел не туда, то ли гугл не понимал чего я хочу. Но я раз за разом натыкался на средства позволяющие лишь восстановить бекап из полной копии и рекурсивно дополнить инкрементальными. Отказаться же от инкрементальных точек в пользу только полных или разностных я не мог из-за ограниченности объёмов приемника бэкапов. И не сказать, что все эти альтернативные средства были для меня бесполезны. Наоборот, я рад тем своим поискам, за такой чудесный продукт как Cobian Backup, которым я пользуюсь до сих пор. Но мой юзкейс они не покрывали.

LightBackup

Позже я нашёл Light Backup — миниатюрная программка, которая делает в точности то, что я и искал — позволяет взглянуть на папку на время создания как полного, так и инкриментального бэкапа.
Правда к этому времени я уже решил свою проблему при помощи BTsync на не-windows сервере, а эта программа работает только под windows.
Но просто пройти мимо я не мог и использую её для некоторых специфичных задач.

Bittorent Sync

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

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

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

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

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

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

  • BTSync как средство бэкапа - 8Нагрузка на 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

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js