Re: Вопросы про бэкапы.
Артём Н. -> debian-russian@lists.debian.org @ 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, по крайней
мере на моих задачах.
Reply to: