Инкрементальный бэкап

Итак, перед нами стоит задача, сбэкапить наш сервер, и не просто сбэкапить, а сделать полный бэкап, и каждый день делать из него разностные бэкапы.

В общем случае, чтобы сделать бэкап любого типа, надо выполнить следующую команду на каждой файловой системе (к примеру, если у нас /var — это отдельная точка монтирования, значит /var надо бэкапить отдельно):

/bin/tar --create --ignore-failed-read --one-file-system --preserve-permissions --recursion --preserve-order --sparse --totals --wildcards --verbose --gzip --file=файл_бэкапа --listed-incremental=файл_метаданных --exclude-from=файл_исключений путь_который_бэкапим

Вкратце опишу, что значит каждый из параметров в данной строке.

1. /bin/tar — собственно, путь к нашему архиватору, если у вас архиватор в другом месте — укажите правильный путь.
2. --create — говорит, что мы создаем архив.
3. --ignore-failed-read — игнорируем файлы, которые не удалось прочитать, вместо останова с ошибкой — бэкап обычно идет автоматически, и лишние сбои бэкапа нам ни к чему.
4. --one-file-system — запрещает бэкапу выходить за пределы файловой системы. Вы спросите, почему бы нам не убрать эту опцию, и не бэкапить все целиком, указав в качестве пути корень (/). Да потому, что в этом случае в бэкап попадет все содержимое системных файловых систем — /dev /proc /sys, и т.д., чего нам в принципе не нужно, и что может послужить поводом для лишних ошибок в процессе развертывания архива. Не-корневые файловые системы со вложенными файловыми системами вы можете смело бэкапить рекурсивно и целиком, убирая этот параметр, но корневую файловую систему без грамотного создания списка исключений так бэкапить нельзя.
5. --preserve-permissions — эта опция говорит архиватору, что мы хотим сохранить все разрешения сохраняемых файлов.
6. --recursion — мы выполняем бэкап всех файлов и каталогов по указанному пути, а также всех файлов и каталогов всех подкаталогов.
7. --preserve-order — при бэкапе мы сохраняем порядок файлов в каталогах, чтобы после восстановления иметь более-менее точные копии и самих каталогов тоже.
8. --sparse — файлы с наличием «пустот» сохраняем именно с указанием мест и длин пустот, а не как файлы с огромным набором нулей.
9. --totals — в конце процесса выводим информацию о том, сколько данных мы сохранили.
10. --wildcards — разрешаем использовать маски (* и ?) в списке исключений — см. ниже.
11. --verbose — вывод подробной информации о процессе. Если вы не ведете лог, или вас не привлекает перспектива видеть весь список сохраняемых файлов на экране — уберите данный параметр.
12. --gzip — сжимаем архив с помощью GZIP. Если не нужно — уберите. —bzip2 не рекомендую, на практике он не дал выигрыша более 10% при сжатии разнородных данных, а вот потери во времени составили около 80%. Однако, если в сжимаемой файловой системе полно текстовых файлов — логи, например — можете попробовать, на тексте он дает ощутимое преимущество.
13. --file=файл_бэкапа — этот параметр указывает путь к создаваемому файлу бэкапа. Убедитесь, что сам этот путь не попадет в бэкап — а лучше — добавьте путь к файлам бэкапа в список исключений.
14. --listed-incremental=файл_метаданных — этот файл управляет говорит, что мы создаем именно бэкап, и управляет уровнем нашего бэкапа. Подробнее смотрите ниже.
15. --exclude-from=файл_исключений — этот файл содержит список исключений — файлов и каталогов, которые не попадут в бэкап. Пути указываются относительно основного пути бэкапа, без начального слеша. Т.е. если мы бэкапим корень (/) и хотим исключить всю папку /backup — пишем просто backup. Допускаются маски, причем на любых уровнях. Допустим, мы бэкапим каталог /www, в котором находятся подкаталоги пользователей, в которых находятся подкаталоги logs, файлы из которых мы не хотим включать в бэкап. Дописываем в файл исключений строчку */logs/*. Вуаля, сами каталоги вида пользователь/logs в бэкап попадают, а вот файлы из них, и подкаталоги — нет.
16. путь_который_бэкапим — это корневой путь, который мы бэкапим. Если бэкапим каталог /www — так и указываем: /www.

Ну вот, параметры разобрали. А теперь к самому интересному. К инкрементальности. Напоминаю про параметр —listed-incremental=файл_метаданных.

Суть в следующем:

1. Если указанного файла не существует — выполняется полный бэкап, а сам файл — создается и заполняется.
2. Если указанный файл существует — выполняется инкрементальный бэкап от момента, определяемого файлом, а сам файл — обновляется.

Итак, мы хотим сделать полный бэкап в понедельник, во вторник — инкрементальный бэкап от состояния понедельника, в среду — от вторника, и т.д. Для этого нам надо:

1. В понедельник бэкапим данные с параметром —listed-incremental=/backup/meta/monday0. При этом файла /backup/meta/monday0 существовать не должно.
2. Во вторник копируем (с заменой) файл /backup/meta/monday0 в файл /backup/meta/tuesday. Затем бэкапим данные с параметром —listed-incremental=/backup/meta/tuesday. Вуаля, мы имеем архив, представляющий собой разность данных между состоянием на момент нашего бэкапа во вторник, и состоянием на момент бэкапа на понедельник.
3. В среду копируем файл /backup/meta/tuesday в файл /backup/meta/wednesday. Затем бэкапим данные с параметром —listed-incremental=/backup/meta/wednesday.
4. И так далее.

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

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

Теперь предположим другой случай. Мы хотим делать полный бэкап в понедельник, а во вторник, среду, и т.п. — делать разность от понедельника. Все делается точно так же, но копию файла метаданных во вторник, среду и т.п. вы делаете перед бэкапом не из файла предыдущего дня, а из файла понедельника. Просто?

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

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

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

Получилось?

Развернуть такой бэкап тоже несложно. Сначала разворачиваем полный (ежемесячный) бэкап на нужный месяц. Потом — недельный бэкап на нужную неделю в этом месяце. А потом — по очереди все дни до нужного нам включительно. Вот и все.

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

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

/bin/tar --extract --ignore-failed-read --preserve-permissions --listed-incremental=/dev/null --recursion --preserve-order --sparse --verbose --gzip --file=файл_бэкапа --directory=путь_для_развертывания

Так же вкратце опишу, что значит каждый из параметров в данной строке.

1. /bin/tar — собственно, путь к нашему архиватору, если у вас архиватор в другом месте — укажите правильный путь.
2. --extract — говорит о том, что мы разворачиваем архив.
3. --ignore-failed-read — игнорируем файлы, которые не удалось прочитать, вместо останова развертывания с ошибкой — даже если что-то не развернулось (бывают файлы хитрого типа — например файлы устройств, которые на целевой системе могут и не развернуться), сбои нам ни к чему, проще почитать лог.
4. --preserve-permissions — эта опция говорит архиватору, что мы хотим восстановить все разрешения восстанавливаемых файлов.
5. --listed-incremental=/dev/null — заметьте, как изменился параметр. При восстановлении файл метаданных роли не играет, однако имя файла все равно требуется. Поэтому мы указываем /dev/null, на функциональность это не повлияет. Указывать —listed-incremental необходимо, поскольку при этом не только восстанавливаются заархивированные файлы и каталоги, но и удаляются занесенные в бэкап удаленные файлы и каталоги (об этом я писал выше).
6. --recursion — мы выполняем развертывание всех файлов и каталогов, а также всех файлов и каталогов всех подкаталогов.
7. --preserve-order — при восстановлении мы сохраняем порядок файлов в каталогах.
8. --sparse — файлы с наличием «пустот» восстанавливаем именно в первозданном виде, а не как файлы с огромным набором нулей.
9. --verbose — вывод подробной информации о процессе. Если вы не ведете лог, или вас не привлекает перспектива видеть весь список восстанавливаемых файлов на экране — уберите данный параметр.
10. --gzip — если архив был сжат с помощью GZIP, не забудьте про этот параметр.
11. --file=файл_бэкапа — этот параметр указывает путь к развертываемому файлу бэкапа.
12. --directory=путь_для_развертывания — путь, куда восстанавливаются файлы. Здесь зарыт небольшой подводный камень. Допустим, мы бэкапили каталог /www/users. Можно предположить, что при восстановлении надо указать тоже /www/users. А вот и нет. Дело в том, что в бэкапе сохраняются полные пути без лидирующего слеша (/). Т.е. все пути сохранились, как www/users/*. Поэтому если мы укажем здесь /www/users — все развернется, как /www/users/www/users. В нашем случае достаточно просто указать /, или использовать опцию —strip-components=N для исключения N начальных элементов пути.

Тэги: , ,

Вы должны залогиниттся ,чтобы оставить комментарий.