Специфичный юзкейс, решаемый в данной статье
Подходит сотрудник с просьбой восстановить файл который вчера/сегодня/только-что удалили, а сейчас он кровь-из-носу понадобился. При этом дату создания файла он не помнит, а дату последнего изменения и знать не знает, ибо с файлом в разное время могли работать множество разных сотрудников. И восстановить нужно, разумеется, последнюю версию.
Либо файл вчера/сегодня/только-что случайно и фатально отредактировали/перезаписали. И восстановить нужно, соответственно, предпоследнюю версию.
Итак, исходные данные:
- Имя файла и его адрес: известны хотя бы примерно
- Дата создания искомой версии файла: не известна
- Бэкап ежедневный, инкрементальный или равный ему по ресурсоёмкости. Полный и разностный не используются ввиду ограниченности объёмов дискового пространства в хранилище/приемнике бэкапов.
Статья вышла слишком «водяная», так что я спрятал основную воду под спойлеры.
Из-за специфики этого юзкейса восстанавливать файл на дату полного бэкапа (если он не ежедневный, а еженедельный/ежемесячный) не имеет смысла, ибо версия будет скорее всего не актуальной. А из инкрементального — затруднительно, ибо дата создания нужной версии файла и соответствующего инкрементального бэкапа не известна.
Разностный бэкап мог бы решить проблему, но он слишком ресурсоёмкий, и далеко не все могут его себе позволить.
Но благо мой предшественник побеспокоился о настройке бэкапов на файловом сервере (Windows Server 2003)Ничтоже сумняшеся я открываю Программа архивации > Восстановление и управление носителем и выпадаю в осадок. Каждая точка бэкапа хранится как отдельная ветвь дерева. При этом бэкап инкрементальный, а значит в каждой отдельной точке лишь новые и изменённые файлы!
И полезли мы с сотрудником перебирать каждую точку начиная со вчерашней и назад. В первый раз нам потребовалось пол дня. В следующий раз почти день. после 3-го раза, я понял что так продолжаться больше не может.
Практически все существующие системы предлагают несколько вариантов бэкапа из списка:
- Полный — создание точек бэкапа с полной копией всех файлов источника
- Инкриментальный — создание точек бэкапа с копией всех файлов, которые появились/изменились за время прошедшее с создания предыдущей точки
- Разностный — создание точек бэкапа с копией всех файлов которые появились/изменились за время прошедшее с создания предыдущей точки полного бэкапа
- Зеркальный — создание и последующая перезапись единственной точки полного бэкапа. Файлы удалённые из в источника, во время бэкапа удаляются из приемника
И то ли я смотрел не туда, то ли гугл не понимал чего я хочу. Но я раз за разом натыкался на средства позволяющие лишь восстановить бекап из полной копии и рекурсивно дополнить инкрементальными. Отказаться же от инкрементальных точек в пользу только полных или разностных я не мог из-за ограниченности объёмов приемника бэкапов. И не сказать, что все эти альтернативные средства были для меня бесполезны. Наоборот, я рад тем своим поискам, за такой чудесный продукт как Cobian Backup, которым я пользуюсь до сих пор. Но мой юзкейс они не покрывали.
Правда к этому времени я уже решил свою проблему при помощи BTsync на не-windows сервере, а эта программа работает только под windows.
Но просто пройти мимо я не мог и использую её для некоторых специфичных задач.
Bittorent Sync
Время шло. В организации появился, а затем остался без дела NAS от QNAP.И как заявляет производитель: «Работать с TS-221 исключительно просто – достаточно лишь щелкать по нужным иконкам!» Что, кстати, не так далеко от истины. Со временем я нащёлкал таким образом Bittorent Sync ещё 1-ой версии
Благо QNAP позаботились обо мне, написав подробную инструкцию по настройке. Правда я не могу сказать что без неё настройка была бы проблемой.
«Роль» системы резервного копирования основывается на следующих функциях/настройках:
- Клиент BTSync должен быть установлен как на источнике так и на приемнике. Это не проблема, ввиду кросплатформенности
* Вообще-то, источником может выступать сетевая папка, так что клиент может быть установлен на другом ПК
** БД (включая настройки) BTSync вроде как хранит отдельно от бинарников, в папке пользователя. Так что теоретически можно запустить 2 независимых интстанса. И сделать источником и приёмником 1 машину
Резервируемые папки должны синхронизироваться на приемник в режиме READ-ONLY.
Вы ведь не хотите, что бы изменения синхронизировались и в обратную сторону?
* Имейте ввиду, что удалённые/изменённые в приемнике файлы больше не будут синхронизироваться, если не поставить галку «Перезаписать любые изменённые файлы». С одной стороны это позволяет аккуратно убирать ненужные для синхронизации файлы, а с другой представляет опасность содержания не-целостных копий. Советую ограничить права на запись/изменение в каталоге приемника для всех кроме пользователя из-под чьего имени работает BTSync.
На приемнике, в параметрах синхронизируемых папок, должен быть включён режим Сохранять удалённые файлы в архиве.
В режиме расширенной настройки, параметр sync_trash_ttl определяет количество дней (макс 30) для хранения файлов в папке архива.- «Расписание» работы в функционал BTSync не входит. Но решается запуском и остановкой приложения через сторонний планировщик (cron и т.п.)
К сожалению, это не позволяет останавливать синхронизацию по логическому завершению, ибо у синхронизации нет как-такового логического завершения. Но меня устраивает режим запуска BTSync в 18:30 и его принудительного завершения в 7:00. За это время источник и приемнике всегда успевают полностью синхронизироваться.
Теперь та же самая просьба сотрудника решается на порядки проще и быстрее. Я просто захожу в приемник в котором структура файлов/папок соответствует вчерашнему (18:30+) состоянию источника. Если же файл был удалён/изменён ранее (в пределах 30 дней) — в путь архива достаточно подставить ".sync\Archive\" и файлы (а так же их версии) тут как тут.
Недостатки такого подхода
Нагрузка на 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 пунктик на эту тему.
Комментарии (25)
chelaxe
27.06.2016 08:00+3Пользуюсь для этого Syncthing`ом.
titulusdesiderio
27.06.2016 08:08В свое время тоже на него наткнулся. Но не было поддержки на моем nas.
Revertis
27.06.2016 09:53+1Я перешёл на Syncthing после того, как несколько раз не мог избавиться от странного поведения BTSync — разные клиенты показывали разное количество файлов в папке. Несколько раз переустанавливал клиенты (Linux, Windows и Android) — ситуация не менялась. А Syncthing отлично синхронизирует мои 35гб уже почти год, и никаких проблем.
ForestQ
27.06.2016 15:03-1Тоже перешел на Syncthing после того, как btsync начал игры с урезанием бесплатной версии. Но Syncthing намного больше жрёт проц/диск при сканировании ;( Благо проект развивается и жду чуда.
Revertis
27.06.2016 16:12Может запилить им issue, чтобы они добавили хотя бы sleep(100) после хэширования каждого файла? :)
Ca5per
27.06.2016 10:33+1Существует еще одна opensource альтернатива — Librevault. Возможно кому-то придется по вкусу.
jok40
27.06.2016 20:52Поставил сейчас на свой забугорный сервер Syncthing — чтобы сравнить скорость с BTsync. Похоже он, как и BTsync, не умеет синхронизировать в несколько потоков: тащит по одному файлу в один поток и, в результате, скорость точно такая-же как у BTsync. Или может надо что-то где-то поднастроить?
Bce_npocTo
27.06.2016 10:33Можете сказать рассматривали ли rsync в качестве альтернативы? И если рассматривали, то почему отказались в пользу btsync
titulusdesiderio
27.06.2016 10:34Рассматривал. Но он не позволяет сохранять предыдущие версии файлов
alex_shpak
27.06.2016 11:04+1rsync --link-destсохраняет снапшоты на определенное время, так что если пользователь помнит время, в которое файл существовал в нужном ему виде, то его легко достать. Список "все предыдущие версии этого файла", правда, так просто не получить.
rsync --backup-dirкопирует предыдущие версии файлов перед их удалением/изменением в другую папку, но чистить её надо как-то по-другому.
jok40
27.06.2016 10:57Скорость — думаю скорость BitTorent протокола ни для кого не секрет.
К сожалению, BTSync в данном случае использует всего один поток, так что особых скоростей тут ожидать не приходится. Может оно, конечно, быстрее работает, чем SMB/FTP, но тем не менее канал используется далеко не на всю катушку.Paramount
27.06.2016 14:25Кстати robocopy умеет многопоточно слать данные и всё это встроено, в качестве зеркала шикарно делает свою работу, гигабитный интерфейс забивал полностью. И это при штатной работе системе видеонаблюдения в это же время. Работает когда запустишь а не когда вздумается.
hamnsk
27.06.2016 11:29отказались от такого решения, уж больно не стабильно, медленно и тд…
как альтернатива syncthingtitulusdesiderio
27.06.2016 11:31У меня несколько лет полет нормальный. Разумеется наши взгляды сугубо субъективны.
ITMatika
27.06.2016 11:49Сам использую BTSync в различных задачах.
Если нужно синхронизовать бэкапы в течение нескольких дней, то вполне годное решение.
Но когда есть изменяемые версии файла, или синхронизация должна гарантированно отработать за несколько минут, то от BTSync пока лучше отказаться.
Jump
27.06.2016 12:52+2BTSync отличный инструмент, и я его постоянно использую для синхронизации.
Но вот для организации бэкапов и версионирования использовать его, думаю не лучшая идея.
Во первых он достаточно тяжелый при индексации, а если применять его по схеме — включил, выключил, это вообще дикая нагрузка на сервер. Если уж пользоваться им, то он должен работать всегда, чтобы не было бессмысленной переиндексации.
Версионирование у него сделано не лучшим образом — при изменении файла, предыдущая версия банально копируется в архив. Копируется полностью. Сто раз изменил файл размером 100мб на один байт — получи 10гб архива.
Особенно если учесть тот факт, что в систему встроен штатный механизм версионирования — теневые копии.
Работает он начиная с Windows XP и server 2013 — хранятся только изменения, быстрый доступ к любой копии.
И никакой нагрузки на сервер и проблем с битыми файлами — перед теневым копированием сбрасываются кэши записи, и происходит оно мгновенно.
По поводу платформозависимости — на других платформах есть не менее хорошие инструменты для этих целей.
А в данном случае это больше похоже на забивание гвоздей микроскопом, при наличии молотка под рукой.
Ivan_83
27.06.2016 13:24+4Я просто фигею от: «Безопасность — все соединения зашифрованы-перешифрованы. У BitTorent пунктик на эту тему.»
Не приходило в голову что это защита от пользователя?
При закрытых исходниках и работе с сетью эта штука запросто может сливать все данные хозяевам софтины, а учитывая шифрование никто кроме них не узнает этого.
ForestQ
27.06.2016 15:07Вообще Shadow Copy встроенный в WinServer более чем решает проблему топикстартера, причем сам юзер может нажать на файле правой кнопкой мыши, Свойства и самому скачать все версии файла.
heathen
А чем shadow copy не устроило плюсом к оффлайновому бэкапу?
titulusdesiderio
Первая реализация этого бэкапа была сделана на Windows Server 2003. А сейчас бы меня устроил. Но есть минус — платформо-зависимость.
Jump
А в чем проблема с теневым копированием на Windows Server 2003?
titulusdesiderio
Сам по себе механизм shadow copy не является средством резервного копирования. Просто на базе него сделано штатное средство в 2012 сервере.
stygian
Простите, но Ваш юзкейс решается теневыми копиями начиная с win 2003
Jump
Разумеется средством резервного копирования shadow copy не является. Это средство снятия снимков файловой системы.
Вам по описанию задачи нужно не резервное копирование, а версионирование, и это отлично решается именно теневыми копиями — делаете теневые копии с нужной частотой. Хоть по три раза в день. Незаметно для пользователя, и практически без нагрузки на сервер.
И хранятся только изменения, и доступ к версиям файлов намного более удобный — просто открываете папку на нужную дату.
А резервное копирование в win server использует механизм теневого копирования уже 15лет.