Как стать автором
Обновить

Комментарии 52

(ещё никто не избегал >/dev/null 2>&1)
#!/bin/sh
echo MWAHAHA > /dev/tty
Обычно сей метод используется для взаимодействия с пользователем утилитами, которые предполагают, что stdin и stdout могут быть перенаправлены (ssh-клиент, например).
Ну если поднапрячься, то я тоже могу придумать ещё несколько способов что-нибудь вывести в обход перенаправления в /dev/null, но зачем?
То что индекс хранится отдельно от данных это крайне приятно. В совокупности с amazon glacier может дать замечательные результаты. В общем, я джва года ждал :)

Единственное, что не радует, так это стабильность самого ПО под вопросом.
Конкретно сейчас ветка все версии dar начиная с 2.4.8 я бы назвал стабильными, благо все новые фичи уже устаканились и были протестированы.

Лично я около полугода использую для своих бэкапов dar (правда я собираю пакет 2.4.12 самостоятельно) и в общем проблем не знаю.
tar не архиватор!
tar — это средство для превращения файловой системы в поток, с которым уже и работает архиватор.
И самое главное что tar стандартизирован в POSIX.
«tar — The GNU version of the tar archiving utility» (с) man GNU tar
«tar — manipulate tape archives» © man BSD tar
tar это как раз архиватор (Tape ARchiver). Но tar не является компрессором, это да.
НЛО прилетело и опубликовало эту надпись здесь
Не путайте архивацию и сжатие!!!
Спасибо! Если честно не знал о таком нюансе. Иногда в комментах на хабре полезное пишут! ;)
НЛО прилетело и опубликовало эту надпись здесь
There's xkcd of it. No exceptions.
Давно пользуюсь, всё ок.
НЛО прилетело и опубликовало эту надпись здесь
Ну если вам интересно, то первые версии tar появились ОЧЕНЬ давно, но тот старый tar имеет достаточно мало общего с нынешними (не забываем про GNU и BSD версии). Нынешнему tar-у всего 13 лет, что, в общем, не так далеко от dar. Ему 11 лет.
Отличная софтина!
Пользуюсь уже, кажется, года три в обвязке из собственных скриптов.
«Поддерживаются gzip, bzip2, lzo»
Этот архиватор имеет собственный компрессор? Какова его степень сжатия в сравнении с другими?
Нет, он линкуется с другими библиотеками и использует их.
а я как-то удовлетворился squashfs-ом.
Жмёт как правило лучше чем .tar.gz
Для доступа просто монтируем образ и тащим всё нужное, вообще не думая о том, что это архив.
squashfs использует gzip, lzma, lzo или xz-сжатие. Сам squashfs ничего не жмет. Но соглашусь, в некоторых случаях squashfs гораздо удобней архивов.
А что делать обладателям бакулы?
Радоваться, что она вам подошла. Я серьёзно. У меня, когда я выбирал чем архивировать, было обязательное условие запуска архиватора от имени пользователя, чего нельзя сделать при использовании бакулы.
Какая скорость сжатия/разворачивания на ваших типовых сценариях?
Я постоянно работаю с двумя сценариями:

1. Бэкап моего ноутбука. Это достаточно много всяких мелких файлов (несколько десятков гигабайт). Архивирование (сжимаю текстовые файлы, не сжимаю картинки и прочие подобные вещи) занимает около 20 минут на SSD. Я его ограничиваю через cgroups, чтобы не падала производительность системы в целом.
2. Бэкап виртуальной машины (SATA диск, сам по себе не очень быстрый) с размещающимися на ней сайтами (около 40Гб разных файлов). Занимает около 40-50 минут.

Плюс я когда искал, у меня был кейс: 500Гб разных файлов (сайты, картинки, большие файлы) всего около нескольких сотен миллионов файлов на SAS 15k диске. Нужно чтобы они бэкапились за ночь. У меня по тестам (я кучу раз распаковывал сорцы ядра и размещал кучу всяких картинок) как раз укладывалось по времени и было не быстрее и не медленнее tar-а, который использовался ранее.

Разворачивание тоже адекватное время занимает. Если нужно распаковать один файл или директорию, то намного быстрее чем tar (благодаря индексам).
Спасибо!
А инкремент сильно быстрее полного бэкапа?
Больше всего при бэкапе тратится времени на операции ввода вывода и инкремент лишь позволяет сохранить разницу, но чтобы эту разницу вычислить, нужно всё равно прочитать весь файл и посчитать для него контрольную сумму. Так что инкрементальный бэкап не даёт прироста скорости.
Как это не дает, если при полном бэкапе эти файлы еще нужно сжать и записать на диск. Кроме того, не знаю есть ли в dar такая фичи, но зачастую можно настраивать, что именно считать обновленным файлом, можно к примеру проверять размер и дату изменения, а не считать хэш всему.
Запись это тоже операция ввода вывода, а сжатие на современных процессорах (например gzip 3..5) выполняется с очень слабой задержкой по времени. Равно как и вычисление контрольных сумм.

Записи то конечно поменьше будет, но это не настолько сильно сказывается на времени работы бэкапа.
Какими бы быстрыми не были сжатие, «чтение + сжатие + запись» в любом будет медленнее только «чтения»
я тут выкладывал статейку, на том архиваторе выигрыш от инкремента был в разы.
Это не к соревнованию между архиваторами, это просто для понимания, что инкремент должен быть быстрее полного бэкапа. И тут вклад «заточенности» алгоритма под инкремент сравним с вкладом операций ввода-вывода.
В целом подход, описанный в вашем посте, мне понравился, спасибо за статью.
Для полного бэкапа, равно как и для инкремента происходит подсчёт контрольных сумм, единственное что при полном бэкапе не происходит — сравнение двух деревьев с контрольными суммами.

Спасибо, я правильно понимаю, что shadow copy это в некотором смысле реализация версионности у Microsoft и система при этом сохраняет предыдущую версию файла? Тогда ничего удивительного что вы получили такой прирост по скорости: исчезли лишние io операции и вероятно ещё какая-то вычислительная нагрузка. Плюс я не уверен, что тест был честный, поскольку при первом прогоне файлы могли быть загружены в оперативную память операционной системы и последующий доступ к ним будет в разы быстрее.
Shadow copy — это технология, которая позволяет делать «снимки» всего диска в заданный момент времени. Т.е. делается снимок, и весь бэкап гарантировано содержит только данные, записанные на диск до момента снимка (это важно при длительных бэкапах — за час работы архиватора можно кучу файлов изменить и не будет целостности данных).

Насчет честности прогонов — уж поверьте на слово, у меня на боевом сервере бэкапы делаются ежедневно, соотношение между полным и инкрементным примерно такое, как я привел в статье.
7zip же всё это умеет и ещё с плюшками (многопоточность и т.п). И уже достаточно стабилен и есть в большинстве дистрибутивов.
Едиственный вопрос — а владельца, права и ссылки этот архиватор сохраняет? TAR используют сугубо потому, что больше файловую систему *nix нельзя упаковать без потерь.
Сохраняет.
С 7zip и другими популярными архиваторами как раз основная проблема в том, что они не умеют сохранять владельца, группу, права, симлинки и другую специфику unix-файлов, поэтому приходится использовать прослойку tar перед архивированием.
Потестил, получил следующую багу:
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" это скорее баг, да. То есть сообщение просто не должно показываться. Я бы отправил багрепорт.
Разобрался, когда делаем дифф — необходимо указывать -J aes:dsfh928efof -K aes:dsfh928efof
То есть ключ для расшифровки, и ключ для шифрования этого же инкребекапа.

Может кому будет полезно — обратите на это внимание.
А автор может чуть подробнее расскрыть, что такое «Декрементальный» бэкап и самое интересное — каким образом комбинация декрементальных и инкрементальных бэкапов позволяет съэкономить место? Чем схема d d d d f i i i i лучше, чем, например, f i i i i i i i?
Определения «Декрементальный бэкап», по правде сказать, не нашел ни в русском, ни в английском варианте.
1. Декрементальный это тоже самое что инкрементальный (то есть сохранающий икремент), только в обратную сторону. То есть из прошлого полного и текущего состояния вычисляется что изменилось по сравнению с текущим и сохраняется полный бэкап, а в прошлом остаются только изменения относительно текущего состояния.

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

Вообще можно ещё в архив добавлять избыточность (dar умеет работать с par2), чтобы можно было восстанавливать даже битые архивы.
Да, спасибо, с механикой бэкапа более-менее понятно, просто раньше не встречал и сходу не нашел в интернетах подробного описания.
А вот насчет комбинаций методов — есть вопросы. В статье вы написали, что «Что позволит обойтись одной полной копией, сэкономив существенное количество места». Интерес вызвал именно момент про экономию места, а вы сейчас отошли в сторону надежности, рассмотрев самый худший исход для инкрементального бэкапа за 2 недели. Ок, но тогда покажите, как должна выглядеть ваша схема из комбинаций d, f и i на диапазоне 16 дней, чтобы было понятно, что последует после
… f +i +i +i +i +i +i
Тогда мы найдем худший исход для такой схемы и сравним потенциальные потери, да?
Спасибо.
Ну декрементальные архивы это как раз фишка dar.

После окончания второй недели идёт неделя декремента: 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 случайных? Гуглил бенчмарки, ничего не нашел.
Индекс для того и существует, чтобы делать вытаскивание файлов моментальным. Открыл файл, прочитал индекс, узнал смещение, перешёл по нему, прочитал файл, закрыл файл.
Это да, но одно дело теория, а другое — практика… Если реализовано все не очень хорошо, то и скорость может быть соответствующая.
Ну я проверял всё это (читал код + смотрел в strace)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории