Артём Н. -> 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 заодно сжимать не умеет? Для задач шифрования это вообще довольно типичное умение - поскольку задача шифрования сама по себе ресурсоемкая, добавить туда предварительное сжатие обычно не только не жалко, но и может повысить производительность. -- 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/87likenlhh....@wizzle.ran.pp.ru
