День добрый комрады. Спустя некоторое время, как я устроился системным администратором, я стал сталкиваться с такой бедой задачей:
Статья вышла слишком «водяная», так что я спрятал основную воду под спойлеры.
Из-за специфики этого юзкейса восстанавливать файл на дату полного бэкапа (если он не ежедневный, а еженедельный/ежемесячный) не имеет смысла, ибо версия будет скорее всего не актуальной. А из инкрементального — затруднительно, ибо дата создания нужной версии файла и соответствующего инкрементального бэкапа не известна.
Разностный бэкап мог бы решить проблему, но он слишком ресурсоёмкий, и далеко не все могут его себе позволить.
Практически все существующие системы предлагают несколько вариантов бэкапа из списка:
«Роль» системы резервного копирования основывается на следующих функциях/настройках:
Теперь та же самая просьба сотрудника решается на порядки проще и быстрее. Я просто захожу в приемник в котором структура файлов/папок соответствует вчерашнему (18:30+) состоянию источника. Если же файл был удалён/изменён ранее (в пределах 30 дней) — в путь архива достаточно подставить ".sync\Archive\" и файлы (а так же их версии) тут как тут.
Специфичный юзкейс, решаемый в данной статье
Подходит сотрудник с просьбой восстановить файл который вчера/сегодня/только-что удалили, а сейчас он кровь-из-носу понадобился. При этом дату создания файла он не помнит, а дату последнего изменения и знать не знает, ибо с файлом в разное время могли работать множество разных сотрудников. И восстановить нужно, разумеется, последнюю версию.
Либо файл вчера/сегодня/только-что случайно и фатально отредактировали/перезаписали. И восстановить нужно, соответственно, предпоследнюю версию.
Итак, исходные данные:
- Имя файла и его адрес: известны хотя бы примерно
- Дата создания искомой версии файла: не известна
- Бэкап ежедневный, инкрементальный или равный ему по ресурсоёмкости. Полный и разностный не используются ввиду ограниченности объёмов дискового пространства в хранилище/приемнике бэкапов.
Статья вышла слишком «водяная», так что я спрятал основную воду под спойлеры.
Из-за специфики этого юзкейса восстанавливать файл на дату полного бэкапа (если он не ежедневный, а еженедельный/ежемесячный) не имеет смысла, ибо версия будет скорее всего не актуальной. А из инкрементального — затруднительно, ибо дата создания нужной версии файла и соответствующего инкрементального бэкапа не известна.
Разностный бэкап мог бы решить проблему, но он слишком ресурсоёмкий, и далеко не все могут его себе позволить.
Попытка использования штатного средства резервного копирования/восстановления в Windows server
Но благо мой предшественник побеспокоился о настройке бэкапов на файловом сервере (Windows Server 2003)
Ничтоже сумняшеся я открываю Программа архивации → Восстановление и управление носителем и выпадаю в осадок. Каждая точка бэкапа хранится как отдельная ветвь дерева. При этом бэкап инкрементальный, а значит в каждой отдельной точке лишь новые и изменённые файлы!
И полезли мы с сотрудником перебирать каждую точку начиная со вчерашней и назад. В первый раз нам потребовалось пол дня. В следующий раз почти день. после 3-го раза, я понял что так продолжаться больше не может.
Но благо мой предшественник побеспокоился о настройке бэкапов на файловом сервере (Windows Server 2003)Ничтоже сумняшеся я открываю Программа архивации → Восстановление и управление носителем и выпадаю в осадок. Каждая точка бэкапа хранится как отдельная ветвь дерева. При этом бэкап инкрементальный, а значит в каждой отдельной точке лишь новые и изменённые файлы!
И полезли мы с сотрудником перебирать каждую точку начиная со вчерашней и назад. В первый раз нам потребовалось пол дня. В следующий раз почти день. после 3-го раза, я понял что так продолжаться больше не может.
Практически все существующие системы предлагают несколько вариантов бэкапа из списка:
- Полный — создание точек бэкапа с полной копией всех файлов источника
- Инкриментальный — создание точек бэкапа с копией всех файлов, которые появились/изменились за время прошедшее с создания предыдущей точки
- Разностный — создание точек бэкапа с копией всех файлов которые появились/изменились за время прошедшее с создания предыдущей точки полного бэкапа
- Зеркальный — создание и последующая перезапись единственной точки полного бэкапа. Файлы удалённые из в источника, во время бэкапа удаляются из приемника
Другие продукты
И начались мои длительные поиски средства, позволяющего взглянуть на папку в том виде, в каком она была несколько дней назад.
И то ли я смотрел не туда, то ли гугл не понимал чего я хочу. Но я раз за разом натыкался на средства позволяющие лишь восстановить бекап из полной копии и рекурсивно дополнить инкрементальными. Отказаться же от инкрементальных точек в пользу только полных или разностных я не мог из-за ограниченности объёмов приемника бэкапов. И не сказать, что все эти альтернативные средства были для меня бесполезны. Наоборот, я рад тем своим поискам, за такой чудесный продукт как Cobian Backup, которым я пользуюсь до сих пор. Но мой юзкейс они не покрывали.
И то ли я смотрел не туда, то ли гугл не понимал чего я хочу. Но я раз за разом натыкался на средства позволяющие лишь восстановить бекап из полной копии и рекурсивно дополнить инкрементальными. Отказаться же от инкрементальных точек в пользу только полных или разностных я не мог из-за ограниченности объёмов приемника бэкапов. И не сказать, что все эти альтернативные средства были для меня бесполезны. Наоборот, я рад тем своим поискам, за такой чудесный продукт как Cobian Backup, которым я пользуюсь до сих пор. Но мой юзкейс они не покрывали.
LightBackup
Позже я нашёл Light Backup — миниатюрная программка, которая делает в точности то, что я и искал — позволяет взглянуть на папку на время создания как полного, так и инкриментального бэкапа.
Правда к этому времени я уже решил свою проблему при помощи BTsync на не-windows сервере, а эта программа работает только под windows.
Но просто пройти мимо я не мог и использую её для некоторых специфичных задач.
Правда к этому времени я уже решил свою проблему при помощи BTsync на не-windows сервере, а эта программа работает только под windows.
Но просто пройти мимо я не мог и использую её для некоторых специфичных задач.
Bittorent Sync
NAS
Время шло. В организации появился, а затем остался без дела NAS от QNAP.
И как заявляет производитель: «Работать с TS-221 исключительно просто – достаточно лишь щелкать по нужным иконкам!» Что, кстати, не так далеко от истины. Со временем я нащёлкал таким образом Bittorent Sync ещё 1-ой версии
Благо QNAP позаботились обо мне, написав подробную инструкцию по настройке. Правда я не могу сказать что без неё настройка была бы проблемой.
BTSync, как средство синхронизации файлов нежели резервного копирования, всё же может выступать и в этой роли. Правда реализуется лишь 1 из 4-х описанных выше вариантов — Зеркальный бэкап. Но с одной принципиально важной особенностью: он умеет сохранять удалённые или предшествующие версии изменённых фалов в течении заданного периода времени.Время шло. В организации появился, а затем остался без дела 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 пунктик на эту тему.
