Архиватор для автоматических бекапов сервера

tar + pixz спасёт ОРД.

zfs, сжатие на лету + мгновенные снапшоты (бекапы)

Rsnapshot, только если бэкапы через WAN, то надо в конфиг добавить

rsync_long_args --timeout=1200 --delete --numeric-ids --relative --delete-excluded
rsync_numtries  4

Расскажите еще, как бекапить миллионы мелких файлов. ext4, debian. Любая работа с ними (cp, tar, rsync) вызывает утечки памяти и адские тормоза.

Duplicity. Плюс duply или deja-dup по желанию.

dar. мегафишка — для определенных расширений (jpg, mp3) можно отключать сжатие. Оно быстрее «gzip -1» раза в 3.

интересно!

zfs, сжатие на лету + мгновенные снапшоты (бекапы)

архиватор хороший, да. Присоветуй тогда ещё к нему надёжную файловую систему.

Присоветуй тогда ещё к нему надёжную файловую систему.

))))

а ты его пробавало, чтобы писать о надежности.

Можно использовать

tar cf - directory | 7za a -si directory.tar.7z

Тогода можно будет выцеплять отдельные файлы?

трудности топикстартера заключаются в особенности (анахронизме, нацеленном на ленты) формата tar, поэтому указанное тобой не поможет ТС, tar никуда не делся

Тогда RAR.

+ мгновенные снапшоты (бекапы)

И как оно для этой цели?

Отлично, невероятное удобство.

DAR - это незаслуженно игнорируемый полезный проект! походу, как раз он является «заменой winrar» c быстрой распаковкой отдельных файлов, шифрованием, информацией для восстановления (par2, да, и немного курить ман). В следующей ветке rar-срача надо будет упомянуть, а пока буду разбираться с DAR, переведу свои личные бекапы на него (с duplicity).

плюсую dar

а ты шутник. Как же я его попробую, если его в ядре нет?

http://opentorrent.ru/imagehost/277031/140518181412f0_0.jpg

да ты че, уж второй год как нативный модуль ядра существует в версии для продакшена.

какой второй год нахер, ядро 3.14 с месяц назад вышло.

ядро 3.14 с месяц назад вышло

)))))))))))))

http://zfsonlinux.org/faq.html

фуу, как всё запущено. чоза ррашка для убунты по ссылке?

эта музыка будет длиться вечно

+ мгновенные снапшоты (бекапы)

снапшот != бекап, к тому же все почему то забывают упоминать о производительности fs в зависимости от количества снапшотов.

rsnapshot

в итоге бэкапы будут весить меньше

снапшот != бекап

кому и корова невеста

забывают упоминать о производительности

просвятите, а то не имею привычки держать овер адын снапшот.

Расскажите еще, как бекапить миллионы мелких файлов. ext4, debian. Любая работа с ними (cp, tar, rsync) вызывает утечки памяти и адские тормоза.

Если dump не поможет, то dd на раздел с "миллионы мелких файлов"

Взрослая система бекапа, которая хранит информацию в БД\

Хотя бы bacula

что есть у взрослой системы, чего нет у детского скрипта?

Топик чисто в традициях лора: не описав толком юскейс и задачу, ТС сходу пускается в дебри описания костылей, которые он сам себе нафантазировал для решения этой задачи.

как раз цель топика уход от bacula :)

Ничего. Спи спокойно

но при этом сжимает и информацию о содержимом архива, то есть чтобы даже посмотреть список файлов в архиве, весом 20ГБ надо дождаться пока он весь распакуется.

tar -cvzf archive.tar.gz /dir/ | tee archive.log

просвятите

Производительность падает. Ваш КО.

а то не имею привычки держать овер адын снапшот.

Простите - то есть у вас не просто снапшот это бэкап, так он у вас еще и всего один ? Ну тогда да - про корову вы очень верно подметили.

у меня два san сервера под zfs, если не заниматься дедупликацией и сращиванием инкрементальных снапшотов, то вопрос о производительности не уместен.

то вопрос о производительности не уместен.

Он неуместен с начала упоминания san. Хотя как видим и его легко просадить скрещиванием снапшотов. А что будет на простых локальных сторажах когда человек по вашему совету начнет пачками делать бэкапы через снапшоты ? То то и оно.

пачками делать бэкапы через снапшоты ?

а что проблема записать снапшот в файл или подключить как отдельную фс, все это прекрасно работает и очень удобно если руки не кривые.

как видим и его легко просадить скрещиванием снапшотов

))))

а что проблема записать снапшот в файл или подключить как отдельную фс, все это прекрасно работает и очень удобно если руки не кривые.

Даж не знаю что сказать ... Как насчет того что бэкапить вообще то нужно не всю fs по которой сделан снапшот ? Как насчет переносимости такого снапшота ? Везде zfs ставить ? А пользователь то всего то файлики хотел бэкапить

бэкапить вообще то нужно не всю fs по которой сделан снапшот ?

и в чем проблема, размещай то что нужно бекапить на фс.

Как насчет переносимости такого снапшота ?

глупости.

Производительность падает.

А что будет с нею при ~сотне R/O почти не отличающихся снапшотов? Просядет ощутимо? И собственно почему?

Чего из этого нет в 7z?

я больше чем уверен что товарищ по настоящему и не нюхал эту фс, как и тот, который нес полную хрень про надежность.

Согласен, DAR - великолепен. Хотя сам пользуюсь rsnapshot.

Информации для восстановления (RS codes) (справедливости ради, в dar она не лучшим образом интегрирована, как выясняется). Callback-ов на _разных_ этапах архивирования (например, по завершении очередного тома) - это, наверно, киллер фича. Выбора алгоритма шифрования.

Но 7z хорош, я не спорю. Я упомянул dar, а не сказал что 7z говно :)

А что будет с нею при ~сотне R/O почти не отличающихся снапшотов?

Примерно то же что с версионной СУБД с сотней перманентно незакрытых транзакций и активной записью.

Грубо на пальцах. При наличии снапшота fs при записи постоянно приходиться проверять блоки на наличие их хотя бы в одном из снапшотов, после чего полностью копировать блок в новое место, и скорее всего строить список блоков по всем снапшотов.

Даже если отбросить время ЦПУ на подобные проверки, остается постоянное размножение одного и того же блока данных. И чем больше снапшотов тем ситуация хуже. И главное - это совершенно лишний оверхед в задаче создания бэкапа.

и в чем проблема, размещай то что нужно бекапить на фс.

«Отличный» совет. Ты забыл добавить «и не размещай на этой fs то что не нужно бэкапить». Типичная проблема курицы и яйца.

На кой такая схема бэкапа - если под неё сразу «геометрию» fs нужно заранее настраивать и молиться что бы потом не возникла необходимость бэкапить что-то что ты не учел при создании fs.

я больше чем уверен что товарищ по настоящему и не нюхал эту фс, как и тот, который нес полную хрень про надежность.

Людям которые считают что снапшот==бэкап бесмысленно что либо объяснять. У них глаза зашорены и они палять из пушки по воробьям.

Любая осмысленная критика и начинается - ты ничего не читал про эту пушку! а ты прикинь какой у неё калибр ! да ты пороху не нюхал ! Да если руки кривые то по воробью не попадаешь !

Смешно ей богу.

Грубо на пальцах. При наличии снапшота fs при записи постоянно приходиться проверять блоки на наличие их хотя бы в одном из снапшотов, после чего полностью копировать блок в новое место, и скорее всего строить список блоков по всем снапшотов.

ох жесть какая херня.

Аргументировано! Убедительно! По делу! Садись пять.

Людям которые считают что снапшот==бэкап бесмысленно что либо объяснять.

поработай с zfs, прежде чем свои домыслы писать

снапшот != бекап

вот это полный бред. снапшот и есть копия данных инкрементальная или полная, а копия данных это и есть бэкап. Для конченных идиотов написано здесь - http://ru.wikipedia.org/wiki/Backup