Пингвинья резервация

Alexander S. Salieff

Спецвыпуск: Хакер, номер #062, стр. 062-066-2

$> crontab -e

0 4 * * * /home/user/backup.sh &> mail 'user@home.ru'

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

Ставим на поток

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

$> cp /dev/hdb /dev/hdc

Обрати внимание на то, что тебя не волнует ни разбиение на разделы, ни форматирование, ни файловая система, ни ее содержимое. Даже если операционка машины-репликатора абсолютно не в состоянии работать с файловой системой воткнутых в нее винчестеров, она все равно сделает правильные копии. В действительности вместо cp лучше пользоваться утилитой dd, так как она специально заточена под поточное копирование бинарных данных и подвергается более тонким настройкам:

$> dd if=/dev/hdb of=/dev/hdc ibs=4096 obs=4096

Приведу другой пример, который лучше соответствует тематике резервного копирования, — создание образа компакт-диска:

$> dd if=/dev/cdrom of=/home/user/mycd.iso bs=2048

Возникает резонный вопрос: «Зачем?» К примеру, чтобы потом прожечь этот образ на болванку, восстановив тем самым диск из бэкапа:

$> cdrecord dev=1,0,0 mycd.iso

Переводить болванки не обязательно, вместо этого можно еще раз вспомнить об универсальности Linux'овой виртуальной ФС плюс подмонтировать образ прямо с винчестера, как loopback-девайс:

$> mount -t iso9660 /home/user/mycd.iso /mnt/cdrom -o loop,ro

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

Спрячем дальше — дольше сохранится

Возникает желание передавать резервируемые данные на другую машину по сети, чтобы обеспечить их максимальную сохранность. Чтобы эта передача была прозрачной для резервирующих приложений, применим, к примеру, уже упомянутую NFS или SMBFS либо станем контролировать сетевой транспорт самостоятельно. Для последнего выберем SSH-сессию. Да, неоригинально. Зато надежно. Проще всего воспользоваться утилитой scp, входящей в комплект OpenSSH:

$> tar -zc -f mybackup.tar.gz srcdir && scp mybackup.tar.gz dstuser@dsthost.ru:/home/dstuser/ && rm -f mybackup.tar.gz

Однако это не удовлетворяет моему требовательному подходу: промежуточный архив mybackup.tar.gz требует места на диске и при этом может оказаться весьма немаленьким. В ситуации, когда непозволительно временно сохранять промежуточный архив на локальном диске, будем архивировать не на диск, а прямо в SSH-сессию. Архиватор будет выдавать архив в stdout (опция -f -), который через pipe-конвейер попадает в stdin SSH-клиента, а оттуда — прямо в сетевую SSH-сессию: