Re: Вопросы про бэкапы.
Артём Н. -> debian-russian@lists.debian.org @ Sun, 27 May 2012 10:38:15 +0400:
>> >> может подойти rsnapshot
>> >> последний месяц или чтото - более частые , сливающиеся в более редкие.
>> >>
>> >> на основе rsync я и самописно делал инкрементальную бекапилку.
>> >> но rsnapshot таки получше будет.
>> АН> О, я смотрел про него. Но как-то не оценил. А какие у него преимущества?
>> АН> И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап является, в
>> АН> принципе, полным, только файлы не копируются, а создаются ссылки?
>> АН> Хм... Т.е., сжатие там никак не сделать?
>>
>> Сжатая файловая система? Во всяком случае, вариант шифрованного
>> обратно-инкрементального бэкапа я сделал именно по этому пути.
АН> Т.е. бэкап делать в файл, который монтировать, как loop?
http://code.google.com/p/fusecompress/. Сам, правда, не пользовался, врать не буду.
>> Прямо-инкрементальный лучше делать таром, он все необходимое умеет.
АН> Ээ... А возможно подробнее: что такое обратно-инкрементальный и
АН> прямо-инкрементальный?
Прямо-инкрементальный - это как делает большинство бэкапных утилит:
берется полный в какой-то момент, и дальше бэкапятся только те файлы,
которые изменились с предыдущего бэкапа.
Обратно-инкрементальный - это когда у тебя хранится в качестве полного
последняя копия, а предыдущие (на случай, если захочется восстановить
файл, удаленный по ошибке месяц назад) хранятся как разница между собой
и следующим. Ну, в случае rsnapshot они все хранятся как полные, только
используются хардлинки на совпадающие файлы.
Прямо-инкрементальный лучше обратно-инкрементального тем, что для
создания следующей копии не требуется доступ к предыдущей, достаточно
знать момент ее создания. А хуже тем, что для восстановления последней
версии (а обычно нужно восстановить именно ее) приходится накатывать всю
последовательность, начиная с полного бэкапа.
>> Когда мне хотелось шифровать бэкап gpg (для нескольких ключей), с
>> невозможностью для автоматики бэкап-сервера расшифровать предыдущий
>> бэкап, я делал инкременталку таром.
АН> А как это реализовано? Шифровался только уже неиспользуемый бэкап или как-то
АН> менялись ключи?
Бэкап шифровался на лету, pgp умеет шифровать поток. Бэкап-сервер
получал уже зашифрованный бэкап. Зашифрованный, если вдруг не понято,
pgp - то есть так, что расшифровать могут только те люди, которые были
предусмотрены в момент шифрования. Бэкап-сервер таким человеком (и
вообще человеком) не является, и расшифровать бэкап поэтому не может.
Поэтому компрометация бэкап-сервера не приводит к компрометации
хранящихся на нем бэкапов.
АН> Насчёт тара: инкрементальный бэкап вы делали без полного копирования предыдущего
АН> и применения tar -g, затем (с копированием в статье было сделано)?
Типа того. Короче, штатными средствами, описанными в info tar. (Я,
прежде чем применить написанное на заборе, обычно лезу в штатную
документацию.)
АН> P.S.:
АН> Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
Кстати, к вопросу о сжатии. LUKS заодно сжимать не умеет? Для задач
шифрования это вообще довольно типичное умение - поскольку задача
шифрования сама по себе ресурсоемкая, добавить туда предварительное
сжатие обычно не только не жалко, но и может повысить
производительность.
Reply to: