# find / -newer /root/startdate -print > /root/modfiles

n  Отредактировать список, добавив туда необходимые файлы и каталоги.

Список, полученный таким способом, нужно периодически обновлять (обычно при изменении конфигурации). Иногда проще добавить целый каталог, чем разбираться с отдельными файлами – tar архивирует каталоги целиком и нет смысла добавлять файлы из каталога, если добавлен каталог (cpio ведет себя по-другому). Не забудьте также про опцию –X, она может понадобиться, если потребуется исключить отдельные файлы и каталоги.

Резервное копирование теперь выполняется так:

srv# tar -I /root/modfiles -cf - | ssh backup@backup "umask 077; cat | gzip > arcname.tgz"

Теперь, выбрав период резервного копирования, можно добавить запись в crontab.

Фактически создан довольно удобный «sandbox», в который можно сбрасывать все что угодно. Но сброшенный туда файл – еще не совсем резервная копия в строгом смысле этого слова. Резервную копию необходимо обезопасить от любых последующих воздействий. Классический метод, которым это обычно делается – запись копии на ленту с последующей ротацией лент и периодическим откладыванием их в архив. Но если у вас есть ленточный накопитель достаточной емкости, совсем необязательно создавать на диске промежуточные копии. Можно сразу указать вместо arcname.tgz имя файла устройства (пользователя backup потребуется включить в группу operator), а cat заменить на dd:

srv# tar -I /root/modfiles -cf - | ssh backup@backup "dd of=/dev/sa0 obs=20b"

Если же ленточного накопителя нет, в качестве сменного носителя можно выбрать компакт-диски. Они далеко не так удобны как ленты, хотя их и можно использовать напрямую почти так же как последние, лишь сменив dd на burncd (для ATA CD-RW):

srv# tar -I /root/modfiles -cf - | ssh backup@backup "burncd data - fixate"

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

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

Конечно, сервера резервного копирования далеко не новость. Выше показано лишь как можно сделать нечто подобное стандартными средствами UNIX, не углубляясь в дебри программирования. Не хватает только одной детали: после создания копии она должна быть перенесена за пределы chroot-окружения пользователя backup.

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