Продолжаю цикл постов о нашем домашнем сервере. Сегодня буду писать о резервном копировании данных - или бэкапе, как его называют айтишники.

У бэкапа, как известно, две основных беды: во-первых, его всегда лень делать, а во-вторых - для него жаль места. Поэтому, когда наступает час X, часто выясняется, что последний бэкап был сделан год назад, и к тому же, как назло, самое важное и нужное именно сейчас как раз и не было скопировано.

Впрочем, бывает и еще обиднее. Лет десять назад у меня навернулся 80-гигабайтник - диск по тем временам весьма немалых размеров. И то, что я делал относительно регулярные бэкапы, меня не спасло - потому что я делал их на другой логический раздел того же самого жесткого диска. Весь размер своей глупости я осознал слишком поздно. Я почему-то тогда больше боялся вирусов и собственных кривых ручек (в равной степени способных порушить файловую систему) чем физической смерти винчестера. Верно говорят, в смерть трудно поверить, пока не увидишь ее своими глазами...

Так что бэкап должен обязательно делаться на другой физический носитель. Конечно, возможны ситуации, когда и это может не спасти - например, пожар, потоп или кража квартиры с выносом всей техники - но это все-таки риски уже совсем другого порядка..

С какой стороны подойти к бэкапу

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

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

По задумке, схема резервного копирования предполагалась следующей:
- на “бэкапном” диске заводится несколько каталогов - по одному на каждый из компьютеров;
- эти каталоги делаются доступными с этих компьютеров через локальную сеть;
- на каждом компьютере отбираются области, подлежащие резервному копированию;
- создается первоначальная резервная копия и складывается на сервер;
- каждую ночь делается инкрементная копия: изменения, произошедшие на компьютере за последние сутки, “подшиваются” к основному архиву.

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

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

Знакомство с Акронисом

Первой программой, которую мы попробовали, был Акронис. Достаточно распространенная система с очень внятной, хотя и не очень подробной документацией. Привлек он, помимо всего прочего, еще и тем, что позволяет делать полный образ системного раздела. Это значит, что если вдруг система по тем или иным причинам навернется, можно ее не переустанавливать, а восстановить из архива, как было. Очень удобно. В теории :) На практике проверять не доводилось - хотя, по-хорошему, надо бы хотя бы один раз обкатать тестовое восстановление, чтобы потом сюрпризов не было.

Первое копирование, конечно, длилось очень долго: копирование десятков гигабайт по локальной сети - процесс небыстрый. Но в дальнейшем все пошло довольно гладко: каждую ночь где-то за полчаса-час все изменения сливались в архив, помечались сегодняшней датой и складывались рядышком. Через каждый из этих архивов можно было получить все файлы, находившиеся на компьютере в момент создания этого архива. Можно было тут же, не сходя с места, открыть Акронисовским проводником архив за любую дату, посмотреть, что там внутри, погулять по папкам и даже скопировать с сервера к себе на компьютер.

Проблемы начались, когда прошел месяц.

Сначала я чуть поподробнее расскажу, что такое инкрементный архив. Это копия данных с компьютера за первый день, плюс длинная цепочка каждодневных изменений этих самых данных. Нетрудно догадаться, что достаточно повредить хотя бы один архив в этой цепочке - и все последующие архивы также окажутся непригодными для использования..

Естественно, такой риск меня не устраивал, поэтому в настройках я указал, что глубина архива должна быть не более 30 дней. Согласно этим настройкам, при превышении заданной глубины Акронис должен был “подбирать хвост”, объединяя основной, первый архив с одним из последующих.

При работе с удаленным диском, находящимся в локальной сети, эта процедура оказалась безумно долгой. За ночь Акронис не успел завершить резервное копирование, и стало понятно, что такая схема нас не устраивает.

К сожалению, я тогда то ли не догадался, то ли просто руки не дошли попробовать заменить инкрементное копирование дифференциальным (когда каждый последующий архив включает в себя изменения не от последнего архива, а от самого начала), поэтому я просто оставил цепочку инкрементных архивов расти без ограничений.

Когда грянул гром (умер один из жестких дисков на компьютере жены), оказалось, что в цепочке архивов, отвечающих за этот диск, поврежден фрагмент годовалой давности. До сих пор не могу понять, как это получилось - но факт, что в итоге данные удалось восстановить только в то состояние, в котором он был год назад. Все, что там появилось за последний год было потеряно.

К этому моменту уже накопилось некоторое количество нареканий и к поведению Акрониса. В частности, когда он работает, делать что-то еще на машине невозможно - и иногда он напрочь игнорирует команды “остановить операцию”. Короче говоря, он не оправдал надежд (и уплаченных за него денег), поэтому было принято решение искать другие решения.

Общие впечатления от Акрониса.
Плюсы: легко настраивается, практически во всем интуитивно понятен, умеет снимать и восстанавливать образы системного диска целиком.
Минусы: стоит денег, местами довольно своенравен и, как показывает практика, не слишком надежен.

Новая идеология: rsync и rsnapshot

Методикой резервного копирования при помощи UNIX-утилиты под названием rsync я заинтересовался давно, когда прочитал про нее в одной пространной статье, посвященной сложностям бэкапа под Windows. Меня привлекло то, что rsync оптимизирована под работу через сеть. Она находится по обе стороны сети: и на той машине, с которой делается бэкап, и на той, на которую он пишется. Это позволяет передавать информацию об изменениях, не перекачивая по сетке все файлы целиком, а отправляя только служебную информацию, позволяющую сравнить файлы и их содержимое, что чертовски экономит время.

Кроме очень эффективной работы по сети, у rsync есть еще одно преимущество. Заключается оно в том, что создаваемые ею резервные копии можно размещать на диске при помощи механизма жестких ссылок - этим занимается утилита rsnapshot, являющаяся надстройкой над rsync. Таким образом, бэкапы, созданные при помощи rsnapshot, можно представить в виде обычных папок, датированных определенным числом, куда можно зайти и получить состояние системы на определенный день. Но при этом те файлы, которые не менялись, не занимают лишнего места, поскольку их имена во всех папках являются ссылками на одно и то же физическое тело файла.

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

Разумеется, у такой великолепной схемы не может быть минусов:
- rsync работает только в среде UNIX;
- для работы rsnapshot файловая система должна поддерживать жесткие ссылки;
- необходимо отдельно озаботиться ограничением доступа на запись к архивным папкам, созданным при помощи rsnapshot, так как случайное изменение файла из архива повлечет нарушение его целостности;
- работа на уровне данных, а не на уровне файловой системы, не позволяет создавать архив с идентичным образом диска.

Все то же самое, только под Windows: cwRsync

В природе существует такая замечательная штука, как cygwin - маленькая программа для создания UNIX-среды в Windows. Когда речь заходит о чем-то, что работает только под UNIX, но хотелось бы запустить это под Windows, первым делом вспоминают про cygwin.

Так вот, на базе cygwin был создан cwRsync - аналог rsync, работающий под Windows, что позволяет распространить преимущества rsync на Windows-машины. cwRsync существует в двух ипостасях:
- собственно, программа rsync, которую можно запустить под Windows;
- Windows-сервис, предоставляющий извне доступ к данным, подлежащим резервному копированию (напомню, идеология rsync предполагает наличие утилиты по обе стороны сети).

Насколько я понимаю, недавно cwRsync стал коммерческим продуктом, но бесплатную версию по-прежнему можно скачать здесь. О том, как его настраивать, написано здесь.

Как устроено резервное копирование у меня

На сервере, на двухтерабайтнике, отведенном под бэкап, есть четыре каталога:
- localhost - бэкап операционной системы самого сервера;
- bfly-laptop - бэкап моего ноутбука;
- julia-mac - бэкап Юлиного iMac;
- ostankin-web - бэкап этого сайта;

Поскольку резервное копирование осуществляется со стороны Linux-сервера, на ноутбуке мне потребовалось установить только cwRscync-сервис, обслуживающий те каталоги, которые я хочу бэкапить. Все остальные машины являются UNIX-системами, на них ничего дополнительно ставить не потребовалось.

Отдельно следует отметить, что для доступа ко всем удаленным машинам потребовалось настроить беспарольный доступ на к ним с сервера через ssh по ключу. О том, как это сделать, рассказано в замечательной статье на linsovet.com.

После чего можно настраивать rsnapshot. В rsnapshot.conf на сервере прописано следующее:

# local system
backup  /boot/          localhost/
backup  /bin/           localhost/
backup  /home/          localhost/
backup  /etc/           localhost/
backup  /lib/           localhost/
backup  /root/          localhost/
backup  /sbin/          localhost/
backup  /usr/           localhost/
backup  /var/           localhost/

# ostankin.net website
backup  ostankin@ostankin.net:/home/ostankin/rsync/     ostankin-web/
backup  ostankin@ostankin.net:/home/ostankin/public_html/       ostankin-web/

# Vlad’s laptop
backup  bfly-laptop::drive_d/Documents/ bfly-laptop/
backup  bfly-laptop::drive_d/Stuff/     bfly-laptop/

# Julia’s iMac
backup  julia@imac:/Users/julia/        julia-mac/

Соответственно, каждую ночь rsnapshot просыпается по расписанию и начинает по различным сетевым протоколам собирать со всех четырех хостов изменения, произошедшие за последние сутки. Отдельно на хостинге запускается задача ежедневного архивирования базы данных блога.

В результате у меня на сервере хранится семь ежедневных бэкапов глубиной в неделю, а также четыре еженедельных бэкапа глубиной в месяц:

vlad@bfly-server:/mnt/backup/rsnapshot$ ll
total 4
drwxr-x--- 13 root adm  4096 Dec 27 03:29 .
drwxr-xr-x 10 root root  119 Aug 21 20:25 ..
drwxr-xr-x  7 root root   92 Dec 27 04:02 daily.0
drwxr-xr-x  7 root root   92 Dec 26 04:03 daily.1
drwxr-xr-x  7 root root   92 Dec 24 04:07 daily.2
drwxr-xr-x  7 root root   92 Dec 23 04:08 daily.3
drwxr-xr-x  7 root root   92 Dec 22 04:07 daily.4
drwxr-xr-x  7 root root   92 Dec 21 04:02 daily.5
drwxr-xr-x  7 root root   92 Dec 20 04:06 daily.6
drwxr-xr-x  7 root root   92 Dec 17 04:05 weekly.0
drwxr-xr-x  7 root root   92 Dec 10 04:01 weekly.1
drwxr-xr-x  7 root root   92 Dec  3 05:51 weekly.2
drwxr-xr-x  7 root root   92 Nov 26 04:00 weekly.3

Акронис был также оставлен (раз уж мы все равно за него заплатили), но теперь он занимается исключительно бэкапом системных разделов - единственной задачей, которая не под силу rsync.

Что еще посмотреть на тему бэкапов?

Во-первых, очень рекомендую почитать статью “Померяемся бэкапами?”, написанную профессиональным Windows-администратором, где он на пальцах рассказывает, что такое бэкапы и с чем их едят. Мне эта статья попалась на глаза очень поздно, поэтому большую часть граблей, описанных там, я собрал самостоятельно :)

Во-вторых, хочу упомянуть пару систем, которые люди мне рекомендовали из личного опыта (к сожалению, обе строго англоязычные):
- Cobian Backup - бесплатный аналог Акрониса.
- CrashPlan - распределенная система для бэкапа “в облако”. Кроссплатформенная и очень умная. Платная, причем плата взимается не за саму систему, а за место в облаке. Есть возможность бэкапиться бесплатно на компьютеры друзей (причем доступа к самим данным у них не будет - они только предоставляют место).