Видео смотреть бесплатно

Смотреть красивый видео

Официальный сайт aksakal 24/7/365

Смотреть видео бесплатно

le087 25.08.2012 11:24

Я рекомендуюОрганизация инкрементальных бекапов за 5 минут

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

Для организации простого инкрементального бекапа я хочу предложить использовать утилиту rdiff-backup. Эта штука написана на python и использует в качестве основы rsync.

Создание бекапов


Найти в репозиториях своего дистрибутива, думаю, не составит труда.
В создании бекапов также проста как rsync:
1
rdiff-backup /source/path /destination/path


В результате в /destination/path будет создано зеркало каталога /source/path.
Если мы внесем какие-либо изменения в /source/path, а потом выполним команду бекапа повторно, утилита определит, что именно изменилась и добавить копию только изменившихся файлов, а может даже только изменившуюся часть этих файлов, хотя фиг знает. В любом случае появится новый слепок каталога.
Посмотреть наличие слепков можно командой:
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
rdiff-backup -l /destination/path
Found 18 increments:
increments.2012-07-14T21:51:05+06:00.dir Sat Jul 14 21:51:05 2012
increments.2012-07-15T21:51:03+06:00.dir Sun Jul 15 21:51:03 2012
increments.2012-07-15T22:02:30+06:00.dir Sun Jul 15 22:02:30 2012
increments.2012-07-16T21:51:08+06:00.dir Mon Jul 16 21:51:08 2012
increments.2012-07-19T21:51:08+06:00.dir Thu Jul 19 21:51:08 2012
increments.2012-07-25T21:51:02+06:00.dir Wed Jul 25 21:51:02 2012
increments.2012-07-27T21:51:04+06:00.dir Fri Jul 27 21:51:04 2012
increments.2012-07-28T21:51:08+06:00.dir Sat Jul 28 21:51:08 2012
increments.2012-07-30T21:51:04+06:00.dir Mon Jul 30 21:51:04 2012
increments.2012-07-31T21:51:09+06:00.dir Tue Jul 31 21:51:09 2012
increments.2012-08-01T21:51:03+06:00.dir Wed Aug 1 21:51:03 2012
increments.2012-08-07T21:51:03+06:00.dir Tue Aug 7 21:51:03 2012
increments.2012-08-11T21:51:06+06:00.dir Sat Aug 11 21:51:06 2012
increments.2012-08-12T21:51:07+06:00.dir Sun Aug 12 21:51:07 2012
increments.2012-08-13T21:51:03+06:00.dir Mon Aug 13 21:51:03 2012
increments.2012-08-16T21:51:08+06:00.dir Thu Aug 16 21:51:08 2012
increments.2012-08-19T21:51:03+06:00.dir Sun Aug 19 21:51:03 2012
increments.2012-08-23T00:38:15+06:00.dir Thu Aug 23 00:38:15 2012
Current mirror: Sat Aug 25 01:25:01 2012


Утилита делает инкремент только в том случае, если были внесены какие-то изменения в файлы и каталоги со времени последнего выполнения бекапа. Благодаря этому мы получаем ряд полезных плюшек:

  1. Возможность экономить дисковое пространство. Если я не ошибаюсь, инкременты делаются до тех пор, пока их суммарный объем не превысит половины объема от последнего полного бекапа. Когда это случается, делается снова полный бекап
  2. Возможность вернуться не просто к последнему бекапу, а бекапу за определенное число
  3. Управлять всем этим хозяйством чертовски просто

Что бы получить краткую сводку после выполненного бекапа, достаточно в команду внести опцию --print-statistic
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
rdiff-backup --print-statistic /source/path /destination/path
--------------[ Session statistics ]--------------
StartTime 1345877958.00 (Sat Aug 25 12:59:18 2012)
EndTime 1345878004.57 (Sat Aug 25 13:00:04 2012)
ElapsedTime 46.57 (46.57 seconds)
SourceFiles 33020
SourceFileSize 467469521 (446 MB)
MirrorFiles 1
MirrorFileSize 0 (0 bytes)
NewFiles 33019
NewFileSize 467469521 (446 MB)
DeletedFiles 0
DeletedFileSize 0 (0 bytes)
ChangedFiles 1
ChangedSourceSize 0 (0 bytes)
ChangedMirrorSize 0 (0 bytes)
IncrementFiles 0
IncrementFileSize 0 (0 bytes)
TotalDestinationSizeChange 467469521 (446 MB)
Errors 0
--------------------------------------------------


Восстановление данных


Что бы восстановить данные, необходимо выполнить команду вида:
1
rdiff-backup -r now /destination/path /local/path


В результате мы восстановим данные из последнего выполненного бекапа в каталог /local/path.
Поскольку в /destination/path хранится полное дерево того, что мы бекапим, то можно указать для восстановления только определенный файл или каталог, например так:
1
rdiff-backup -r now /destination/path/some/directory/or/file /local/path


Чувствую пятой точкой, как минимум глоббинг здесь так же должен работать, но не проверял.
Что бы восстановить файлы 5 дневной давности, можно воспользоваться такой командой:
1
rdiff-backup -r 5D /destination/path/some/directory/or/file /local/path


Можно восстановить и по определенной дате:
1
rdiff-backup -r 2012-08-05 /destination/path/some/directory/or/file /local/path

, но в этом нужно сначала просмотреть список доступных инкрементов, после чего указать TIMESTAMP того, что Вам нужен:
1
rdiff-backup -r 2012-08-13T21:51:03+06:00 /destination/path/some/directory/or/file /local/path


Удаляем старое


Естественно, что хранить кучу устарвешего файла 5 лет нет смысла. Rdiff-backup умеет и прибирать за собой. Давайте удалим бекапы старше, чем 16 недель:
1
rdiff-backup --remove-older-than 16W /destination/path


Удаление старых бекапов происходит таким образом, что если в тот день имеется только инкремент полного бекапа, то останется все предыдущие до момента создания этого инкремента бекапы вплоть до предыдущего полного бекапа. Таким образом гарантируется, что удаление старых бекапов не приведет к неработоспособности оставшихся инкрементов.

Немного сладкого напоследок


Поскольку rdiff используется для работы rsync, то естественно он умеет делать бекапы на удаленный хост. Команда для создания бекапов в этом случае выглядит примерно так:
1
rdiff-backup /source/path user@backup-host::/destination/path

Аналогично можно проводить восстановление данных и просмотр уже сделанных бекапов. Для автоматизирования создания бекапов и удаления старых необходимо будет сделать очевидные вещи:

Вот небольшой мини скрипт бекапа, написанный мною на скорую руку:
1
2
3
4
5
6
7
8
#!/bin/bash
# backup script with using rdiff-backup

if ping -c 1 -s 1 -W 1 backup-server
then
rdiff-backup /source/path user@backup-server::/destination/path
rdiff-backup --remove-older-than 16W user@$backup-server::/destination/path
fi

При необходимости пишем логи, настраиваем отправку отчетов по электронной почте.



Тэги: rdiff-backup бекап
+ 9 -
Похожие Поделиться

CryptSpirit 25.08.2012 12:50 #
+ 0 -
Уже несколько месяцев бекапы своего сервера и ноутбука делаю через rdiff-backup. В принципе доволен. Хотя с одно стороны бекап хома длиться до часа (большое число вложений, даже при том что я отключаю файлы больше 10Мб и каталоги музыки, и видео). Нагрузки почти не создает. за статью спасибо узнал пару новых вещей. Хотя у rdiff-backup и критики много, но и она в сторону старых версий программы
le087 25.08.2012 13:02 #
+ 0 -
На работе у меня rdiff-backup используется почти для всего, что нужно бекапить. Для хранения данных пользователей у нас имеется пара десятков террабайт дискового пространства, из которого 60% уже заняты. Бекапы делаются ежедневно. Возможно это не самый быстрый способ, но поскольку есть реальный пример использования, то делюсь именно им.
CryptSpirit 25.08.2012 14:15 #
+ 0 -
У меня на работе еще не разу не использовали rdiff-backup, потому что свои сценарии резервного копирования настраиваются только на нагруженных и очень важных серверах. Используется rsync, потому что там не до экспериментов.
le087 25.08.2012 14:33 #
+ 0 -
Учитывая то, что он все равно использует тот же самый rsync можно сказать, что rdiff-backup тоже самое, только с оберткой, написанной на питоне. У меня очень положительный, пока что по крайне мере, опыт использования этой штуки. Rsync чаще всего мне приходиться использовать для копирования данных и синхронизации каталогов, а сабж вот для организации бекапов удобен.
Да я с Вами согласен, это вполне нормально, что его не везде получиться использовать.
CryptSpirit 25.08.2012 15:28 #
+ 0 -
Лично я испытываю его до того момента пока не придется реально заняться восстановлением. Так сказать боевые условия. Какой у Вас опыт в восстановлении данных через rdiff-backup. Часто восстанавливали и были проблемы?
le087 25.08.2012 15:33 #
+ 0 -
Да постоянно приходится восстанавливать, каждый день почти, такова специфика организации.
dan 25.08.2012 13:01 #
+ 1 -
А на жёстких ссылках оно умеет делать бэкапы?
le087 25.08.2012 13:26 #
+ 0 -
Ну если верить описанию программы на главной странице проекта: "rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, modification times, extended attributes, acls, and resource forks."; то оно должно хорошо справлятся и с хардлинками.

Может я не правильно понял вопрос и имеется в виду, будет ли делаться бекап того файла, хардлинк которой бекапиться? Насколько мне известно hardlink не выйдет сделать на какой-либо каталог, а вот на файлы их можно делать. Хард линк указывает на inode файла, соответственно пока есть хотя бы один хардлинк на файл, он не будет удален из файловой системы. Отсюда можно сделать вывод, хардлинки и файлы на которые они ведут так же должны бекапиться. Лучший способ - проверить на практике. На своей памяти я не помню проблем с хардлинками при использовании rdiff-backup.
le087 25.08.2012 15:35 #
+ 0 -
PS хороший вопрос
dan 25.08.2012 15:57 #
+ 0 -
Нет, я не имел ввиду бэкап жёстких ссылок, я имел ввиду бэкап на основе жёстких ссылок. То есть каждый раз, когда делаем новый бэкап, делается полный бэкап, но если файл не изменялся, то вместо него создаётся жёсткий линк на уже забэкапленный. Если обновился - то кладётся новая версия. В результате только микроскопический оверхед на директории и сами ссылки, в плюсе - отсутствие необходимости в полном бэкапе, т.к. любой бэкап всегда имеет полную версию данных.
le087 25.08.2012 16:44 #
+ 0 -
Я не уверен, что оно работает так. Насколько я знаю, оно рботает немного по-другому.

Сначала делается полный бекап. После этого, предположим, мы внесли несколько изменений в содержимое каталога, которое бекапим. Следующий бекап сделает инкремент, который будет содержать только разницу между предыдущим и текущем состояниями каталога. Еще одно резервное копирование создасть инкремент, который будет содержать разницу между предыдущем бекапом и предыдущем инкрементом и текущем состоянием каталога и так далее. При извлечение данных из резервной копии сначала берется полный бекап, а затем на него накатываются накопившиеся до нужного нам момента инкременты, после чего отдается уже пользователю на растерзание. В этом случае, наверно, нет необходимости создавать жесткие ссылки, но должна появится некая копилка информации о каждом слепке, которая знает состояние зарезервированного каталога в каждый раз из сделанных бекапов.
ar2r 25.08.2012 18:47 #
+ 0 -
Я для этого использую bontmia
А у вас какое решение?
le087 25.08.2012 19:52 #
+ 0 -
Отлично! Будет классно, если Вы напишите небольшую заметку о том, что используете. Если честно, о bontmia я слышу впервые =)
GalS 25.08.2012 13:17 #
+ 0 -
инкремент
le087 25.08.2012 13:28 #
+ 0 -
Спасибо, поправил.
ladykosha 25.08.2012 14:05 #
+ 0 -
Большое спасибо. Надеюсь, этого мне хватит, чтобы перестать собираться, и таки начать делать. :)))
mealsforall 25.08.2012 20:29 #
+ 1 -
Хорошая статья. Я бы только в последнем скрипте между созданием бекапа и удалением старых поставил бы проверку успешности первой строки. А то, скажем, новые бэкапы перестали создаваться из-за какой-нибудь проблемы, а старые потихонечку исчезаааааают...
le087 25.08.2012 22:01 #
+ 0 -
Хм, да, согласен. Хорошее примечание.
mealsforall 25.08.2012 20:30 #
+ 0 -
distanation -> destination :)
le087 26.08.2012 00:57 #
+ 0 -
Исправил, спасибо.
xandry 25.08.2012 22:10 #
+ 0 -
> как rsyns

В конце букву исправьте.
le087 26.08.2012 00:57 #
+ 0 -
Спасибо большое, поправил.
blackraven 27.08.2012 16:51 #
+ 0 -
TIMESHTAMP -> TIMESTAMP
le087 28.08.2012 22:45 #
+ 0 -
пофиксил, благодарю

Смотреть видео онлайн

Онлайн видео бесплатно


Смотреть русское с разговорами видео

Online video HD

Видео скачать на телефон

Русские фильмы бесплатно

Full HD video online

Смотреть видео онлайн

Смотреть HD видео бесплатно

School смотреть онлайн