Comments 52
(ещё никто не избегал >/dev/null 2>&1)
#!/bin/sh
echo MWAHAHA > /dev/tty
То что индекс хранится отдельно от данных это крайне приятно. В совокупности с amazon glacier может дать замечательные результаты. В общем, я джва года ждал :)
Единственное, что не радует, так это стабильность самого ПО под вопросом.
Единственное, что не радует, так это стабильность самого ПО под вопросом.
tar не архиватор!
tar — это средство для превращения файловой системы в поток, с которым уже и работает архиватор.
И самое главное что tar стандартизирован в POSIX.
tar — это средство для превращения файловой системы в поток, с которым уже и работает архиватор.
И самое главное что tar стандартизирован в POSIX.
UFO just landed and posted this here
Давно пользуюсь, всё ок.
UFO just landed and posted this here
Отличная софтина!
Пользуюсь уже, кажется, года три в обвязке из собственных скриптов.
Пользуюсь уже, кажется, года три в обвязке из собственных скриптов.
«Поддерживаются gzip, bzip2, lzo»
Этот архиватор имеет собственный компрессор? Какова его степень сжатия в сравнении с другими?
Этот архиватор имеет собственный компрессор? Какова его степень сжатия в сравнении с другими?
а я как-то удовлетворился squashfs-ом.
Жмёт как правило лучше чем .tar.gz
Для доступа просто монтируем образ и тащим всё нужное, вообще не думая о том, что это архив.
Жмёт как правило лучше чем .tar.gz
Для доступа просто монтируем образ и тащим всё нужное, вообще не думая о том, что это архив.
А что делать обладателям бакулы?
Какая скорость сжатия/разворачивания на ваших типовых сценариях?
Я постоянно работаю с двумя сценариями:
1. Бэкап моего ноутбука. Это достаточно много всяких мелких файлов (несколько десятков гигабайт). Архивирование (сжимаю текстовые файлы, не сжимаю картинки и прочие подобные вещи) занимает около 20 минут на SSD. Я его ограничиваю через cgroups, чтобы не падала производительность системы в целом.
2. Бэкап виртуальной машины (SATA диск, сам по себе не очень быстрый) с размещающимися на ней сайтами (около 40Гб разных файлов). Занимает около 40-50 минут.
Плюс я когда искал, у меня был кейс: 500Гб разных файлов (сайты, картинки, большие файлы) всего около нескольких сотен миллионов файлов на SAS 15k диске. Нужно чтобы они бэкапились за ночь. У меня по тестам (я кучу раз распаковывал сорцы ядра и размещал кучу всяких картинок) как раз укладывалось по времени и было не быстрее и не медленнее tar-а, который использовался ранее.
Разворачивание тоже адекватное время занимает. Если нужно распаковать один файл или директорию, то намного быстрее чем tar (благодаря индексам).
1. Бэкап моего ноутбука. Это достаточно много всяких мелких файлов (несколько десятков гигабайт). Архивирование (сжимаю текстовые файлы, не сжимаю картинки и прочие подобные вещи) занимает около 20 минут на SSD. Я его ограничиваю через cgroups, чтобы не падала производительность системы в целом.
2. Бэкап виртуальной машины (SATA диск, сам по себе не очень быстрый) с размещающимися на ней сайтами (около 40Гб разных файлов). Занимает около 40-50 минут.
Плюс я когда искал, у меня был кейс: 500Гб разных файлов (сайты, картинки, большие файлы) всего около нескольких сотен миллионов файлов на SAS 15k диске. Нужно чтобы они бэкапились за ночь. У меня по тестам (я кучу раз распаковывал сорцы ядра и размещал кучу всяких картинок) как раз укладывалось по времени и было не быстрее и не медленнее tar-а, который использовался ранее.
Разворачивание тоже адекватное время занимает. Если нужно распаковать один файл или директорию, то намного быстрее чем tar (благодаря индексам).
Спасибо!
А инкремент сильно быстрее полного бэкапа?
А инкремент сильно быстрее полного бэкапа?
Больше всего при бэкапе тратится времени на операции ввода вывода и инкремент лишь позволяет сохранить разницу, но чтобы эту разницу вычислить, нужно всё равно прочитать весь файл и посчитать для него контрольную сумму. Так что инкрементальный бэкап не даёт прироста скорости.
Как это не дает, если при полном бэкапе эти файлы еще нужно сжать и записать на диск. Кроме того, не знаю есть ли в dar такая фичи, но зачастую можно настраивать, что именно считать обновленным файлом, можно к примеру проверять размер и дату изменения, а не считать хэш всему.
я тут выкладывал статейку, на том архиваторе выигрыш от инкремента был в разы.
Это не к соревнованию между архиваторами, это просто для понимания, что инкремент должен быть быстрее полного бэкапа. И тут вклад «заточенности» алгоритма под инкремент сравним с вкладом операций ввода-вывода.
В целом подход, описанный в вашем посте, мне понравился, спасибо за статью.
Это не к соревнованию между архиваторами, это просто для понимания, что инкремент должен быть быстрее полного бэкапа. И тут вклад «заточенности» алгоритма под инкремент сравним с вкладом операций ввода-вывода.
В целом подход, описанный в вашем посте, мне понравился, спасибо за статью.
Для полного бэкапа, равно как и для инкремента происходит подсчёт контрольных сумм, единственное что при полном бэкапе не происходит — сравнение двух деревьев с контрольными суммами.
Спасибо, я правильно понимаю, что shadow copy это в некотором смысле реализация версионности у Microsoft и система при этом сохраняет предыдущую версию файла? Тогда ничего удивительного что вы получили такой прирост по скорости: исчезли лишние io операции и вероятно ещё какая-то вычислительная нагрузка. Плюс я не уверен, что тест был честный, поскольку при первом прогоне файлы могли быть загружены в оперативную память операционной системы и последующий доступ к ним будет в разы быстрее.
Спасибо, я правильно понимаю, что shadow copy это в некотором смысле реализация версионности у Microsoft и система при этом сохраняет предыдущую версию файла? Тогда ничего удивительного что вы получили такой прирост по скорости: исчезли лишние io операции и вероятно ещё какая-то вычислительная нагрузка. Плюс я не уверен, что тест был честный, поскольку при первом прогоне файлы могли быть загружены в оперативную память операционной системы и последующий доступ к ним будет в разы быстрее.
Shadow copy — это технология, которая позволяет делать «снимки» всего диска в заданный момент времени. Т.е. делается снимок, и весь бэкап гарантировано содержит только данные, записанные на диск до момента снимка (это важно при длительных бэкапах — за час работы архиватора можно кучу файлов изменить и не будет целостности данных).
Насчет честности прогонов — уж поверьте на слово, у меня на боевом сервере бэкапы делаются ежедневно, соотношение между полным и инкрементным примерно такое, как я привел в статье.
Насчет честности прогонов — уж поверьте на слово, у меня на боевом сервере бэкапы делаются ежедневно, соотношение между полным и инкрементным примерно такое, как я привел в статье.
7zip же всё это умеет и ещё с плюшками (многопоточность и т.п). И уже достаточно стабилен и есть в большинстве дистрибутивов.
Едиственный вопрос — а владельца, права и ссылки этот архиватор сохраняет? TAR используют сугубо потому, что больше файловую систему *nix нельзя упаковать без потерь.
Едиственный вопрос — а владельца, права и ссылки этот архиватор сохраняет? TAR используют сугубо потому, что больше файловую систему *nix нельзя упаковать без потерь.
Потестил, получил следующую багу:
1. Делаю dar -R /etc -c /etc_full -zbzip2:9 -K aes:dsfh928efof
Это сделает full бекап директории /etc.
2. Делаю dar -R /etc -c /etc_diff -A /etc_full.1.dar -zbzip2:9 -J aes:dsfh928efof
Что сделает собсно дифференциальный бекап.
Причем хочу обратить внимание на то, что испльзуется сжатие(-zbzip2:9) bzip2 с уровнем 9, и aes шифрование с ключом dsfh928efof. При этом, как указано в документации:
Для шифрования указывайте ключ -K. Eсли применяете опцию -A, которая позволяет делать дифференциальные бекапы, то испльзуйте опцию -J вместо -K.
Ну ок, на данном этапе вроде как никаких неприятностей нет.
3. Делаем dar -x /etc_diff.1.dar -R /tmp/etc -K aes:dsfh928efof, чтобы распаковать дифференциальный бекап, на что получаем ответ
FATAL error, aborting operation
Error while decyphering data: User defined source 1/Invalid length
Но, стоит только поменять ключ -K на ключ -J, мы получаем
-J is only useful with -A option, for the archive of reference
Но все прекрасно распаковыватся.
Бага? Как фиксить? Что делаю не так?
И еще — не нашел как скипать сообщения, требующие ввода enter или esc от пользователя.
Вышенаписанное проверял как на dar в стандартном репозитории ubuntu 12.04.4, так и на свежей вверсии, собранной с сорцов с офф сайта.
1. Делаю dar -R /etc -c /etc_full -zbzip2:9 -K aes:dsfh928efof
Это сделает full бекап директории /etc.
2. Делаю dar -R /etc -c /etc_diff -A /etc_full.1.dar -zbzip2:9 -J aes:dsfh928efof
Что сделает собсно дифференциальный бекап.
Причем хочу обратить внимание на то, что испльзуется сжатие(-zbzip2:9) bzip2 с уровнем 9, и aes шифрование с ключом dsfh928efof. При этом, как указано в документации:
Для шифрования указывайте ключ -K. Eсли применяете опцию -A, которая позволяет делать дифференциальные бекапы, то испльзуйте опцию -J вместо -K.
Ну ок, на данном этапе вроде как никаких неприятностей нет.
3. Делаем dar -x /etc_diff.1.dar -R /tmp/etc -K aes:dsfh928efof, чтобы распаковать дифференциальный бекап, на что получаем ответ
FATAL error, aborting operation
Error while decyphering data: User defined source 1/Invalid length
Но, стоит только поменять ключ -K на ключ -J, мы получаем
-J is only useful with -A option, for the archive of reference
Но все прекрасно распаковыватся.
Бага? Как фиксить? Что делаю не так?
И еще — не нашел как скипать сообщения, требующие ввода enter или esc от пользователя.
Вышенаписанное проверял как на dar в стандартном репозитории ubuntu 12.04.4, так и на свежей вверсии, собранной с сорцов с офф сайта.
Не нужно указывать filename.1.dar, нужно указывать просто filename, см «Я думаю, все уже заметили, что название архива никак не упоминает расширение файла .dar. А ещё в имени файла откуда-то взялась цифра 1. Это всё потому, что dar изначально предназначается для бэкапа на сменные носители (CD, DVD или, например, ленточные накопители), поэтому он архивирует в слайсы, а циферка 1 возникает потому, что этот слайс первый.»
Ещё можно указывать -O --no-warn ключи, чтобы скипать сообщения.
"-J same as -K but the given key is used to decrypt the archive of reference" — тут ключевое слово «для расшифровки»
То есть в full мы зашифровываем данные, а потом когда делаем diff — указываем -J потому что нам нужно зашифрованные данные расшифровать.
А вот это сообщение "-J is only useful with -A option, for the archive of reference" это скорее баг, да. То есть сообщение просто не должно показываться. Я бы отправил багрепорт.
Ещё можно указывать -O --no-warn ключи, чтобы скипать сообщения.
"-J same as -K but the given key is used to decrypt the archive of reference" — тут ключевое слово «для расшифровки»
То есть в full мы зашифровываем данные, а потом когда делаем diff — указываем -J потому что нам нужно зашифрованные данные расшифровать.
А вот это сообщение "-J is only useful with -A option, for the archive of reference" это скорее баг, да. То есть сообщение просто не должно показываться. Я бы отправил багрепорт.
А автор может чуть подробнее расскрыть, что такое «Декрементальный» бэкап и самое интересное — каким образом комбинация декрементальных и инкрементальных бэкапов позволяет съэкономить место? Чем схема d d d d f i i i i лучше, чем, например, f i i i i i i i?
Определения «Декрементальный бэкап», по правде сказать, не нашел ни в русском, ни в английском варианте.
Определения «Декрементальный бэкап», по правде сказать, не нашел ни в русском, ни в английском варианте.
1. Декрементальный это тоже самое что инкрементальный (то есть сохранающий икремент), только в обратную сторону. То есть из прошлого полного и текущего состояния вычисляется что изменилось по сравнению с текущим и сохраняется полный бэкап, а в прошлом остаются только изменения относительно текущего состояния.
2. Тем, что если у вас будет один полный и тринадцать инкрементов, то битый, например, первый инкрементальный оставит вас без бэкапов за две недели. А так только за неделю.
Вообще можно ещё в архив добавлять избыточность (dar умеет работать с par2), чтобы можно было восстанавливать даже битые архивы.
2. Тем, что если у вас будет один полный и тринадцать инкрементов, то битый, например, первый инкрементальный оставит вас без бэкапов за две недели. А так только за неделю.
Вообще можно ещё в архив добавлять избыточность (dar умеет работать с par2), чтобы можно было восстанавливать даже битые архивы.
Да, спасибо, с механикой бэкапа более-менее понятно, просто раньше не встречал и сходу не нашел в интернетах подробного описания.
А вот насчет комбинаций методов — есть вопросы. В статье вы написали, что «Что позволит обойтись одной полной копией, сэкономив существенное количество места». Интерес вызвал именно момент про экономию места, а вы сейчас отошли в сторону надежности, рассмотрев самый худший исход для инкрементального бэкапа за 2 недели. Ок, но тогда покажите, как должна выглядеть ваша схема из комбинаций d, f и i на диапазоне 16 дней, чтобы было понятно, что последует после
… f +i +i +i +i +i +i
Тогда мы найдем худший исход для такой схемы и сравним потенциальные потери, да?
Спасибо.
А вот насчет комбинаций методов — есть вопросы. В статье вы написали, что «Что позволит обойтись одной полной копией, сэкономив существенное количество места». Интерес вызвал именно момент про экономию места, а вы сейчас отошли в сторону надежности, рассмотрев самый худший исход для инкрементального бэкапа за 2 недели. Ок, но тогда покажите, как должна выглядеть ваша схема из комбинаций d, f и i на диапазоне 16 дней, чтобы было понятно, что последует после
… f +i +i +i +i +i +i
Тогда мы найдем худший исход для такой схемы и сравним потенциальные потери, да?
Спасибо.
Ну декрементальные архивы это как раз фишка dar.
После окончания второй недели идёт неделя декремента: d- d- d- d- d- d- f и после снова инкременты. Худший исход для такой схемы — потеря полного бэкапа
После окончания второй недели идёт неделя декремента: d- d- d- d- d- d- f и после снова инкременты. Худший исход для такой схемы — потеря полного бэкапа
Таким образом, по вашей схеме, при порче f бэкапа мы точно также потеряем 2 недели бэкапов (худший исход), как и в случае тупо инкрементальных бэкапов. И всё так же не понятен тайный смысл d бэкапа, почему не делать только f и i?
Если я туплю — ткните где, плиз =)
Если я туплю — ткните где, плиз =)
А! Кажись понял. Просто у вас в точке перехода ...+i d-… (декрементальный бэкап от инкрементального — мама-мия) по-сути формируется full бэкап. Тогда да, максимум можно потерять 1 неделю. Но тогда сравнение с 2 неделями инкрементального всё-таки не совсем корректно. Такую схему надо сравнивать с f i i i i i f i i i i i i, а в ней худший исход также 1 неделя.
В общем, что-то не сходится у вас ;)
В общем, что-то не сходится у вас ;)
Возможность сделать избыточность — хорошо, но это уже чуть другая тема, всё таки.
Вопрос к знатокам — насколько быстрый этот архиватор, если брать с индексом? К примеру, если заархивировано 5 миллионов мелких файлов, как быстро можно извлечь 1-2 случайных? Гуглил бенчмарки, ничего не нашел.
разобрался.
Sign up to leave a comment.
Ещё один формат хранения архивов: dar