Артём Н. -> [email protected] @ Sun, 27 May 2012 13:50:08 +0400:
>> >> >> может подойти rsnapshot >> >> >> последний месяц или чтото - более частые , сливающиеся в более >> редкие. >> >> >> >> >> >> на основе rsync я и самописно делал инкрементальную бекапилку. >> >> >> но rsnapshot таки получше будет. >> >> АН> О, я смотрел про него. Но как-то не оценил. А какие у него >> преимущества? >> >> АН> И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап >> является, в >> >> АН> принципе, полным, только файлы не копируются, а создаются ссылки? >> >> АН> Хм... Т.е., сжатие там никак не сделать? >> >> >> >> Сжатая файловая система? Во всяком случае, вариант шифрованного >> >> обратно-инкрементального бэкапа я сделал именно по этому пути. >> АН> Т.е. бэкап делать в файл, который монтировать, как loop? >> http://code.google.com/p/fusecompress/. Сам, правда, не пользовался, врать >> не буду. АН> Сжимать всё? А сжимать один бэкап..? АН> Ну, т.е. сжимать каждый из дневных бэкапов не имеет смысла: изменений мало, а АН> производительность, при полном сжатии, уменьшается. Расслабься, в _этом_ месте вопрос производительности не стоит. Особенно - по сравнению с шифрованием. АН> Достаточно сжать бэкап за месяц. Но, при этом, как я понял, не АН> будут работать инкрементальные бэкапы? Прямо-инкрементальные - будут, им доступ к этому бэкапу не нужен. >> >> Прямо-инкрементальный лучше делать таром, он все необходимое умеет. >> АН> Ээ... А возможно подробнее: что такое обратно-инкрементальный и >> АН> прямо-инкрементальный? >> Прямо-инкрементальный - это как делает большинство бэкапных утилит: >> берется полный в какой-то момент, и дальше бэкапятся только те файлы, >> которые изменились с предыдущего бэкапа. >> Обратно-инкрементальный - это когда у тебя хранится в качестве полного >> последняя копия, а предыдущие (на случай, если захочется восстановить >> файл, удаленный по ошибке месяц назад) хранятся как разница между собой >> и следующим. Ну, в случае rsnapshot они все хранятся как полные, только >> используются хардлинки на совпадающие файлы. АН> Ага, понятно. Хм... Это делает rsnapshot или rsync? rsnapshot перед запуском rsync. Делает cp -al (на не-линуксах эмулирует). АН> И есть ли какие-то побочные эффекты от большого количества АН> хардлинков (ведь придётся в каждом новом бэкапе создавать ссылку на АН> каждый не изменённый файл старого)? Нет. Они же хардлинки, от них даже количество инодов не пухнет. Иноды, правда, кушаются директориями, которые при таком копировании таки создаются. >> Прямо-инкрементальный лучше обратно-инкрементального тем, что для >> создания следующей копии не требуется доступ к предыдущей, достаточно >> знать момент ее создания. А хуже тем, что для восстановления последней >> версии (а обычно нужно восстановить именно ее) приходится накатывать всю >> последовательность, начиная с полного бэкапа. АН> Смотрю в сторону rdiff-backup и rsnapshot или rsync (склоняюсь к первому). АН> Но у обратных бэкапов минус: я не могу сжать полный бэкап. АН> Потому что изменения вносятся в него. АН> Хм... Да и в случае прямого мне не очень понятно... Например, сжал я полный АН> бэкап. Но ведь Его надо распаковывать, чтобы сравнивать, что изменилось? АН> Или должен быть файл с метаинформацией, как в случае с tar? Его нужно распаковывать не столько для того, чтобы сравнить, сколько для того, чтобы поменять. Ведь принцип обратно-инкрементального бэкапа в том, что полной хранится последняя версия. АН> В любом случае, как я понимаю, у обратных бэкапов сжимать полный бэкап АН> возможности нет? В принципе - есть. В принципе ничто не мешает полный бэкап, сжатый хоть тем же .tar.gz, прямо в пайпе разжать, поменять, что нужно, и положить на диск. Однопроходного чтения _в принципе_ достаточно, поэтому место нужно только для двух сжатых - старого и нового (ну и отдельно для изменений, при сем образовавшихся). А вот есть ли для этого готовые инструменты, я сомневаюсь. >> Бэкап шифровался на лету, pgp умеет шифровать поток. Бэкап-сервер >> получал уже зашифрованный бэкап. Зашифрованный, если вдруг не понято, >> pgp - то есть так, что расшифровать могут только те люди, которые были >> предусмотрены в момент шифрования. Бэкап-сервер таким человеком (и >> вообще человеком) не является, и расшифровать бэкап поэтому не может. >> Поэтому компрометация бэкап-сервера не приводит к компрометации >> хранящихся на нем бэкапов. АН> Т.е., сервер только хранил бэкапы, причём бэкап всегда был полный? В том случае мы в итоге делали полные, чтобы не морочиться с инкрементальными при ротации дисков, но прямо-инкрементальным он может быть с легкостью. Сервер еще и запускал процесс - заходил по ssh на бэкапимый линукс, запускал там команду бэкапа (по этому ssh-ключу было разрешено запустить только эту команду), и прямо в это же ssh-соединение получал уже зашифрованный бэкап, который тупым cat'ом клал себе на диск. С виндой было хуже, винда делала бэкап своим встроенным бэкапом (ага, надо было бэкапить отнюдь не только файлы, а и Active Directory), так что винда сама лила свой бэкап по самбе. >> АН> Насчёт тара: инкрементальный бэкап вы делали без полного копирования >> предыдущего >> АН> и применения tar -g, затем (с копированием в статье было сделано)? >> >> Типа того. Короче, штатными средствами, описанными в info tar. (Я, >> прежде чем применить написанное на заборе, обычно лезу в штатную >> документацию.) АН> Да я читал. Всё-равно непонятно возможно ли как-то сливать бэкапы в один (без АН> особых сложностей). Тупо и цинично: просто разворачиваешь их все по очереди в одно и то же место, а потом таришь то, что получилось. При восстановлении потом не таришь, просто разворачиваешь. Идея расписания в том, что периодически делается полный бэкап, и восстановление начинается с него. Если применяются еще и дифференциальные, то на полный накатывается последний дифференциальный, а на него - случившиеся после него инкрементальные. А в один никто не сливает, незачем. >> АН> P.S.: >> АН> Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS. >> Кстати, к вопросу о сжатии. LUKS заодно сжимать не умеет? Для задач >> шифрования это вообще довольно типичное умение - поскольку задача >> шифрования сама по себе ресурсоемкая, добавить туда предварительное >> сжатие обычно не только не жалко, но и может повысить >> производительность. АН> Не, LUKS - это Linux Unified Key System. Только шифрование. К тому АН> же, поверх него ещё ФС (а может и LVM - я уж не помню точно как там АН> у меня сделано). К тому же, сжатие всей ФС мне не очень нужно. Ну и зря. Быстрее бы работало. АН> P.S.: АН> А вы о dar можете что-нибудь сказать? Ничего, кроме того, что мне это слово попадалось. То бишь я даже изучал, что это такое, но сходу не понял, чем оно лучше tar, по крайней мере на моих задачах. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
