Re: Вопросы про бэкапы.
> >> >> может подойти rsnapshot
> >> >> последний месяц или чтото - более частые , сливающиеся в более редкие.
> >> >>
> >> >> на основе rsync я и самописно делал инкрементальную бекапилку.
> >> >> но rsnapshot таки получше будет.
> >> АН> О, я смотрел про него. Но как-то не оценил. А какие у него преимущества?
> >> АН> И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап является, в
> >> АН> принципе, полным, только файлы не копируются, а создаются ссылки?
> >> АН> Хм... Т.е., сжатие там никак не сделать?
> >>
> >> Сжатая файловая система? Во всяком случае, вариант шифрованного
> >> обратно-инкрементального бэкапа я сделал именно по этому пути.
> АН> Т.е. бэкап делать в файл, который монтировать, как loop?
> http://code.google.com/p/fusecompress/. Сам, правда, не пользовался, врать не буду.
Сжимать всё? А сжимать один бэкап..?
Ну, т.е. сжимать каждый из дневных бэкапов не имеет смысла: изменений мало, а
производительность, при полном сжатии, уменьшается.
Достаточно сжать бэкап за месяц. Но, при этом, как я понял, не будут работать
инкрементальные бэкапы?
> >> Прямо-инкрементальный лучше делать таром, он все необходимое умеет.
> АН> Ээ... А возможно подробнее: что такое обратно-инкрементальный и
> АН> прямо-инкрементальный?
> Прямо-инкрементальный - это как делает большинство бэкапных утилит:
> берется полный в какой-то момент, и дальше бэкапятся только те файлы,
> которые изменились с предыдущего бэкапа.
> Обратно-инкрементальный - это когда у тебя хранится в качестве полного
> последняя копия, а предыдущие (на случай, если захочется восстановить
> файл, удаленный по ошибке месяц назад) хранятся как разница между собой
> и следующим. Ну, в случае rsnapshot они все хранятся как полные, только
> используются хардлинки на совпадающие файлы.
Ага, понятно. Хм... Это делает rsnapshot или rsync? И есть ли какие-то побочные
эффекты от большого количества хардлинков (ведь придётся в каждом новом бэкапе
создавать ссылку на каждый не изменённый файл старого)?
> Прямо-инкрементальный лучше обратно-инкрементального тем, что для
> создания следующей копии не требуется доступ к предыдущей, достаточно
> знать момент ее создания. А хуже тем, что для восстановления последней
> версии (а обычно нужно восстановить именно ее) приходится накатывать всю
> последовательность, начиная с полного бэкапа.
Смотрю в сторону rdiff-backup и rsnapshot или rsync (склоняюсь к первому).
Но у обратных бэкапов минус: я не могу сжать полный бэкап.
Потому что изменения вносятся в него.
Хм... Да и в случае прямого мне не очень понятно... Например, сжал я полный
бэкап. Но ведь Его надо распаковывать, чтобы сравнивать, что изменилось?
Или должен быть файл с метаинформацией, как в случае с tar?
В любом случае, как я понимаю, у обратных бэкапов сжимать полный бэкап
возможности нет?
> Бэкап шифровался на лету, pgp умеет шифровать поток. Бэкап-сервер
> получал уже зашифрованный бэкап. Зашифрованный, если вдруг не понято,
> pgp - то есть так, что расшифровать могут только те люди, которые были
> предусмотрены в момент шифрования. Бэкап-сервер таким человеком (и
> вообще человеком) не является, и расшифровать бэкап поэтому не может.
> Поэтому компрометация бэкап-сервера не приводит к компрометации
> хранящихся на нем бэкапов.
Т.е., сервер только хранил бэкапы, причём бэкап всегда был полный?
> АН> Насчёт тара: инкрементальный бэкап вы делали без полного копирования предыдущего
> АН> и применения tar -g, затем (с копированием в статье было сделано)?
>
> Типа того. Короче, штатными средствами, описанными в info tar. (Я,
> прежде чем применить написанное на заборе, обычно лезу в штатную
> документацию.)
Да я читал. Всё-равно непонятно возможно ли как-то сливать бэкапы в один (без
особых сложностей).
> АН> P.S.:
> АН> Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
> Кстати, к вопросу о сжатии. LUKS заодно сжимать не умеет? Для задач
> шифрования это вообще довольно типичное умение - поскольку задача
> шифрования сама по себе ресурсоемкая, добавить туда предварительное
> сжатие обычно не только не жалко, но и может повысить
> производительность.
Не, LUKS - это Linux Unified Key System. Только шифрование. К тому же, поверх
него ещё ФС (а может и LVM - я уж не помню точно как там у меня сделано).
К тому же, сжатие всей ФС мне не очень нужно.
P.S.:
А вы о dar можете что-нибудь сказать?
Reply to: