> >> >> может подойти 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 можете что-нибудь сказать? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc1f8d0.7080...@yandex.ru
