rsnapshot

Есть вариант делать раз в день LVM снапшот и оставлять его. Удалять снапшоты старше 7 дней. Да, может (я не уверен) пострадать скорость записи. Надо обратиться к документации LVM, как там устроено CoW. (Я боюсь, что при записи в оригинальный том, LVM копирует прежние сектора во все снапшоты, сделанные из этого тома).

>rsnapshot
+1

rsnapshot не канает. Он использует хардлинки, т.е. при изменении хоть 1 бита в файле размером 100Г, ты получишь 2 файла по 100Г в бакапе.

А по другому и никак... Откуда программа резервного копирования узнает в каком месте этот самый бит изменился?

Я свелосипедил простой скрипт к xdelta3, результаты пока неплохие.

LVM снапшоты никакие не снапшоты, а обходной доступ к снимку файловой системы на определённый момент времени через виртуальное устройство /dev.

Юзайте dump/restore на живой файловой системе UFS2. Утилиты позволяют работать с инкрементными данными.
Ссылка на статью: http://vds-admin.ru/backup/dump-i-restore-rezervnoe-kopirovanie-i-vosstanovle...

Это все может хорошо, но все же подразумеват FreeBSD, потому в помойку. ;)

Почему в помойку?

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

Твоя проблема не в том что ты занимаешься фаллическим редукционизмом (свод любой темы разговора к ... FreeBSD), а в том что не читаешь заголовков темы. Тебя в этом треде по идее не должно быть, ведь уже сказано что LVM

>А по другому и никак... Откуда программа резервного копирования узнает в каком месте этот самый бит изменился?


rdiff-backup делает бинарный diff. Цитата с сайта:

rdiff-backup uses librsync, which implements the same efficient diffing algorithm that rsync uses. It works on binary files as well as text, so only a fraction of the data in your database would be saved in each incremental backup.

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

4.2.

Тебя в этом треде по идее не должно быть, ведь уже сказано что LVM

ВНЕЗАПНО: на LVM может быть UFS2.

4.2.

Будут рабочие примеры или пук в лужу?

xfsdump. Пуки в лужу — это твоё любимое занятие, не моё.

The xfsdump utility backs up an XFS filesystem in inode order, and in contrast to traditional UNIX file systems which must be unmounted before dumping to guarantee a consistent dump image, XFS file systems can be dumped while the file system is in use. This is not the same as a snapshot since files are not frozen during the dump.

[backup] xfsdump vs dump (комментарий) Помнишь хоть, что сам нашёл? :))

Ну помню. В чём проблема-то? Консистентно? Да. Онлайн? Да. Без привлечения [x]fs_freeze и снапшотов? Да.

Так xfsdump/xfsrestore не поддерживают инкрементного образа ФС или поддерживают? (сомневаюсь)

Пробовал работать с этими утилитами — напиши, что да как. Какие нюансы открылись. В сети информации по ним ноль целых, одна тысячная. По-моему, эта тема от твоего мнения не обеднеет.

> Так xfsdump/xfsrestore не поддерживают инкрементного образа ФС или поддерживают? (сомневаюсь)

А ты не сомневайся, ты ман прочитай.

Поддерживают. Автору темы от этого пользы нет, потому что единицей инкремента выступает отдельный файл (или его отсутствие), а не бинарный дифф :)

И 100 гиговый фвйл он мне будет лопатить как текст?

Там написано, что он лопатит как бинарные данные, так и текст, а не то, что он интерпретирует их как текст.

делаешь mount -o remount,ro <чтототам> lvm snapshot <чтонужно> mount -o remount,rw <чтототам> И будет тебе счастье

Смотри сюда: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Adm...

Да это понятно, просто это я не думаю, что будет быстро для файла в 100 гб. Понимаете? Пока он там найдёт куда новый байтик затисался...

ну, по моим тестам, это происходит все же быстрей, чем копирование всего 100Гб-файла :)

Итого, за минусом холиваров и срачей:

1. rsnapshot не подходит(там действительно линки на файлы, и он будет храниться целиком, если там изменился 1 байт)

2. Про rdiff-backup я написал в первом сообщении. Не производит впечатления нормального решения, в плане реализации. Какие-то ерроры на устаревшие конструкции питона падают, и т.д. По функционалу - то, что нужно.

3. Хранить снапшоты прямо в ЛВМ, не удаляя - хреновая идея. Оно со временем тормозит. Да и речь идет о бекапе не за неделю, а месяца за три.

4. Велосипед к xdelta и rdiff - пока единственный вариант. Но очень хотелось бы его НЕ изобретать. ( товарищ madgnu, выложи куда-нибудь свой велосипед, пожалуйста. Посмотрю как сделано)

Какие еще предложения?

Еще раз повторю - суть не в том что это снапшоты lvm(точнее их дампы). Считайте что есть просто файлы большого объема.

>3. Хранить снапшоты прямо в ЛВМ, не удаляя - хреновая идея. Оно со временем тормозит. Да и речь идет о бекапе не за неделю, а месяца за три.

У тебя же записи мало. А тормозить (да и то, не факт, что заметно) оно будет только на запись, не на чтение. Попробуй.

Записи много. В lvm томах лежат диски виртуальных машин. Так что не вариант. Да и не надежно. Если навернется группа томов - то вместе с бекапами. Зачем нужен такой бекап?

>не прибегая к отмонтированию.

man xfs_freeze, гений

тьфу ты, xfsdump конечно же, freeze - это шняга... Надо больше спать и меньше работать...

а с корневой системой проканает?

а что мешает изменить схему разделов, чтобы нужные директории находились в отдельном томе lvm