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

Alexander S. Salieff

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

$> rdiff-backup -r now dstuser@dsthost.ru::dstdir srcdir

И вот так, если мы вознамеримся восстановить данные из бэкапа 10-дневной давности:

$> rdiff-backup -r 10D dstdir srcdir

$> rdiff-backup -r 10D dstuser@dsthost.ru::dstdir srcdir

В директории хранилища, предназначенного для инкрементальных диффов, создается каталог rdiff-backup-data/increments — отсюда можно восстанавливать конкретные диффы, которые имеют имя формата <filename><timestamp>.diff.gz. И таким образом мы получаем способ восстановления конкретного файла из конкретного диффа:

$> rdiff-backup dstuser@dsthost.ru::dstdir/file.2005-10-30T02:13:56+04:00.diff.gz srcdir/file

Проблема очистки диска от устаревших резервных копий тоже решается встроенными средствами пакета. Допустим, требуется удалить все данные «старше» двух недель:

$> rdiff-backup --remove-older-than 2W dstuser@dsthost.ru::dstdir

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

Базы данных просят резерва

Полезные данные СУБД нуждаются в резервном копировании не меньше других файлов. Обычно типовые дистрибутивы комплектуются следующими СУБД: MySQL и PostgreSQL. На них и будем оттачивать приемы резервного копирования.

Обычно табличные данные в MySQL свалены в определенный каталог, в котором имеется набор подкаталогов, одноименных с базами данных. В наборе подкаталогов уже содержится набор файлов, которые олицетворяются таблицами. Подсмотреть расположение этого каталога (обычно это /var/lib/mysql) можно в конфигурационном файле (обычно /etc/my.cnf) в переменной datadir-секции [mysqld]. Этот каталог (со всеми содержащимися подкаталогами и файлами) бэкапится любым из перечисленных мной способов, как и обычные бинарные файлы. Если планируется заниматься этим при работающем демоне MySQL, то во избежание ошибок когерентности лучше копируй файлы с помощью mysqlhotcopy. Mysqlhotcopy согласует свои действия с демоном, позволяя избежать рассинхронизации данных. Однако, к сожалению, он умеет делать только локальные копии, и в большинстве случаев может работать только из-под рута, независимо от имеющихся прав в самой СУБД MySQL:

$root> mysqlhotcopy mydbname /bkpdir/mysqlbackup/

Резервирование бинарных файлов СУБД — это, конечно, хорошо, но что делать, когда планируется перенос БД на другую СУБД, бинарно не совместимую с текущей (возможно, даже не MySQL)? В таких случаях используется mysqldump, которая транслирует содержимое БД в набор инструкций стандарта SQL99. Полученный набор воспроизводится на любой СУБД, лишь бы та поддерживала стандарт SQL99:

$> mysqldump --add-drop-table --add-locks --all --quick --lock-tables mydbname > result.sql

Была отдана вот эта команда (см. выше), и тут мой result.sql плюс ко всему прочему стал содержать вот такое создание и заполнение таблицы, вполне понятное для любой SQL СУРБД:

-- Table structure for table `mytable`