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

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

В общем случае, чтобы сделать бэкап любого типа, надо выполнить следующую команду на каждой файловой системе (к примеру, если у нас /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 начальных элементов пути.

Теги: , ,

Ви повинні залогінитися ,щоб залишити коментар.