Ещё один формат хранения архивов: dar

    Введение



    Есть известная поговорка, что системные администраторы делятся на три типа: тех, кто не делает бэкапы; тех, кто уже делает бэкапы и тех, кто делает и проверяет, что бэкапы рабочие.

    Однако этого недостаточно, и сейчас для пользователя системы бэкапов важен такой параметр как скорость, причём не только скорость самого бэкапа, то есть архивирования файлов, но и восстановления.

    Согласитесь, ведь глупо считывать целиком весь архив размером в 50-100-1000 гигабайт, чтобы извлечь один файл.

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

    И именно этим вы будете заниматься, если будете использовать формат архива TAR. Ведь это промышленный стандарт для архивов, и он используется во многих утилитах для бэкапа.

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

    У TAR вообще много недостатков, многие из них — фатальные. Я приведу небольшой список основных недостатков, на которые натолкнулся за время исследования:

    • Отсутствие индекса, и как следствие — невозможность вытащить один файл, не считывая весь архив.
    • Зоопарк форматов: GNU tar разных версий, BSD tar тоже разных версий, которые подразумевают иногда несовместимость архивов между собой.
    • Отсутствие встроенного шифрования.
    • Невозможность селективного сжатия (зачем нам, например, сжимать jpeg?).
    • Совершенно невнятные ошибки при архивации и при восстановлении (типичным сообщением об ошибке является «Unexpected EOF of archive», которое может обозначать что угодно).
    • Он может просто не сделать архив, например, потому что часть файлов была удалена во время архивации, и tar никак эту ситуацию не обрабатывает.


    И это только то, что я вспомнил с ходу.

    Я провёл достаточно обширное исследование архиваторов (zip, rar, 7zip) и даже всяких монструозных систем для бэкапов: опенсорсных (ну или условно опенсорсные) типа bacula, и проприетарных.

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

    Я предлагаю вам обратить внимание на архиватор dar и коротко расскажу о его преимуществах и недостатках (они есть, но их немного, и с ними можно жить), а потом перейду к практическим примерам.

    Достоинства



    • У файла архива есть индекс, и даже больше — сам индекс можно разместить отдельно и забэкапить, что позволит восстановить архив, если у него был повреждён индекс.
    • Не только привычные дифференциальный и инкрементальный бэкапы, но и декрементальный.
    • Шифрование (blowfish, aes, twofish, serpent, camelia).
    • Можно сжимать файлы с определёнными расширениями.
    • Можно не сжимать файлы с определёнными расширениями.
    • Можно гибко управлять процессом архивации и разархивации (как реагировать на удаление файлов, на изменение, перемещение и пр.).
    • Есть поставляемый с dar менеджер архивов, он позволяет не восстанавливать все архивы подряд при поисках файла, автоматически выбирая только нужные.


    Это только основные его преимущества, вообще dar очень богат на фичи и об этом лучше всего говорит цитата из man: «...But due to the lack of available unused letter for command line options...».

    Проект достаточно активно развивается и хорошо поддерживается разработчиком. На свои вопросы я получал ответ в течении пары дней, причём ответы всегда очень содержательны. Я знаю только один проект с таким же уровнем поддержки — libguestfs, к слову, я про него уже писал.

    Недостатки



    • Нереальное количество опций, а если всерьёз закапываться в то, как реагировать на различные изменения файлов при архивации/разархивации — свихнуться можно.
    • Совершенно неочевидный процесс архивации/восстановления через пайп (например, по ssh).
    • В определённых ситуациях dar может потребовать реакции пользователя (это решается через добавление аргументов к команде, но, как правило, эта интерактивность проявляется очень неожиданно, особенно пока вы пишете свои первые скрипты с dar).


    Не то, чтобы это недостаток, но dar очень многословен. Если tar после выполнения операции напишет одну строчку, то dar пишет очень много и очень подробно. И конечно, его можно заткнуть (ещё никто не избегал >/dev/null 2>&1).

    Практикум



    Я готов поспорить, что часть аудитории уже побежала устанавливать dar в своих любимых дистрибутивах и читать man'ы самостоятельно. Для тех же, кто остался, я расскажу как им пользоваться. А когда энтузиасты вернутся, я покажу, как пользоваться этой замечательной утилитой, и расскажу о некоторых базовых понятиях, которые вы встретите на страницах man dar.

    Архивирование



    Первый пример, самый простой:

    dar -R $HOME -c /mnt/backup/archive


    Архивирует директорию /home.

    Давайте исключим пару директорий (~/movies, ~/downloads):

    dar -R $HOME -c /mnt/backup/archive -P movies -P downloads


    Я думаю, все уже заметили, что название архива никак не упоминает расширение файла .dar. А ещё в имени файла откуда-то взялась цифра 1. Это всё потому, что dar изначально предназначается для бэкапа на сменные носители (CD, DVD или, например, ленточные накопители), поэтому он архивирует в слайсы, а циферка 1 возникает потому, что этот слайс первый. А поскольку мы не указывали ключик -s 100M — и единственный. У dar есть также ключи для запуска скриптов, при выполнении определённых операций (такие ключи есть и у tar). Например, когда слайс записан, можно выполнить скрипт и поменять носитель, а потом ещё раз и так далее.

    В общем, разбитием архива на несколько частей никого не удивишь.

    По умолчанию dar архивирует без сжатия, и чтобы включить сжатие нужно передать ему ключик -z algo:level. Поддерживаются gzip, bzip2, lzo. И на выходе мы получим такой же файл .N.dar, без добавления всяких .gz и прочих. Архиватор сам знает что у него внутри.

    Перейдём к следующей вкусности — исключениям для сжатия при архивации:

    dar -R $HOME -c /mnt/backup/archive -Y "*.txt" "*.fb2" -Z "*.mp4"


    Ключ -Y указывает для каких файлов нужно включать компресию, а -Z — для каких не нужно. Причём по умолчанию исключение имеет более высокий приоритет (но это поведение можно поменять при необходимости).

    А теперь приступим к дифференциальному, инкрементальному и самому вкусному — декрементальному бэкапу.

    Если кто-нибудь не знает, что это означает — нестрашно, я расскажу:

    • Дифференциальный: сначала создаётся полная копия, а каждый последующий день сохраняется только разница между этой копией и текущим состоянием файлов.
    • Инкрементальный: создаётся полная копия, на следующий день сохраняется разница между полной и текущим состоянием, на третий — разница между вторым днём и третьим.
    • Декрементальный: каждый день сохраняется полная копия и сохраняется разница между текущим состоянием и вчерашним.


    При этом вам никто не мешает реализовывать одновременно и инкрементальный, и декрементальный бэкап. Так что за две недели бэкап может выглядеть так (сверху дни недели, снизу тип бэкапов d- — декрементальный, +i — инкрементальный):

    M T W T F S S M T W T F S
    d- d- d- d- d- d- f +i +i +i +i +i +i


    Что позволит обойтись одной полной копией, сэкономив существенное количество места.

    Следует также знать, что единственным, что вам понадобится для того чтобы сделать инкрементальный архив — индекс. В терминах dar индекс называется каталогом, а сохранение индекса в файл — изоляцией каталога. Также я далее буду использовать только термины инкрементальный/декрементальный, поскольку дифференциальный архив — частный случай инкрементального

    Итак, давайте создадим инкрементальный архив:

    dar -R $HOME -c /mnt/backup/archive_monday -A /mnt/backup/archive


    А теперь сделаем ещё один:

    dar -R $HOME -c /mnt/backup/archive_tuesday -A /mnt/backup/archive_monday


    Идею поняли? Отлично, едем дальше. А сейчас давайте сохраним индекс отдельно (обратите внимание, мы его не вырежем из архива, а просто скопируем, это как с бэкапом mbr. Вы ведь делаете бэкап своего загрузчика?), чтобы потом не ворочать многогигабайтным бэкапом только ради создания инкрементного архива. Мы делаем сейчас «изоляцию на лету», но каталог можно сохранить в любое удобное время, взяв его из готового архива.

    dar -R $HOME -c /mnt/backup/archive_wednesday -A /mnt/backup/archive_tuesday -@ /mnt/backup/CAT_archive_wednesday


    А теперь давайте сделаем бэкап ещё разок, используя только индекс CATarchivewednesday:

    dar -R $HOME -c /mnt/backup/archive_thursday -A /mnt/backup/CAT_archive_wednesday -@ /mnt/backup/CAT_archive_thursday


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

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

    dar -R $HOME -c /mnt/backup/archive_sunday
    dar -R $HOME -+ /mnt/backup/archive_saturday_decremental -A /mnt/backup/archive_saturday -@ /mnt/backup/archive_sunday -ad


    Вообще, тут немного всё запутано (привыкайте), поскольку -+ по документации создан для объединения двух архивов, а -@, как мы уже говорили, служит для изоляции каталога «на лету», и ключ -ad меняет поведение этих ключей, чтобы реализовать декремент. В некотором смысле это логично. Наверное.

    Ну вот мы и подобрались к моменту истины — восстановлению данных. Ведь все понимают, что сделанный бэкап, который нельзя восстановить, равносилен несделанному бэкапу?

    Перед восстановлением было бы неплохо проверить архив:

    dar -t /mnt/backup/archive_sunday

    Если dar не вернул код ошибки (в конце man'а перечислены все возможные коды выхода, которые dar может вернуть), то можно восстанавливать:

    mkdir sunday
    dar -x /mnt/backup/archive_sunday -R sunday

    Операции на удалённых машинах



    Восстановление файлов



    Я вскользь уже упоминал, что восстановление файлов с удалённых машин, через пайп (например, по ssh) является нетривиальной задачей.

    Попробую подробно рассказать как это работает.

    Все сложности связаны с тем, что для восстановления одного файла dar нужно читать индекс. Если же использовать его аналогично tar, в режиме потокового чтения (ключ --sequential-read), то таких проблем не возникает.

    Для решения проблемы с чтением индекса создано две версии dar:

    • Основная: dar, которая говорит, что нужно восстановить.
    • Вспомогательная: dar_slave, которая принимает команду и передаёт dar восстановленные данные, которые dar потом записывает на диск.


    Поэтому схема работы (для восстановления) выглядит так:

    (2) --> dar --> (1) --> dar_slave archive --> (2)


    1. dar через пайп говорит dar_slave: «Хочу восстановить файл А».
    2. dar_slave считывает индекс файла archive, узнаёт, по какому смещению находится искомый файл, и передаёт его на stdout, который читает dar и пишет полученный файл на диск.


    Сложность заключается в том, чтобы осуществить передачу файла от dar_slave в dar. Для такой «кольцевой» передачи данных нам придётся соорудить небольшой костыль при помощи mkfifo:

    mkfifo /tmp/fifo<.code>
    dar -x -i /tmp/fifo -R sunday | ssh user@host dar_slave sunday > /tmp/fifo

    rm /tmp/fifo

    Этих проблем можно избежать, если монтировать удалённую директорию, например, по NFS.

    Упаковка файлов



    При упаковке файлов тоже есть небольшая хитрость: нужно обязательно сохранять файл индекса архива на локальной машине, чтобы на его основе можно было строить инкрементальные архивы:

    dar -R $HOME -c - -A /mnt/backup/CAT_archive_wednesday -@ /mnt/backup/CAT_archive_thursday | ssh user@host 'cat > archive_thursday'


    Разные приятности



    Также в комплекте с dar идёт утилита под названием dar_manager, которая является обёрткой на стероидах над dar. По сути, это приложение, которое, оперируя полученными из архивов индексами, позволяет упростить жизнь при восстановлении данных (например, не придётся копаться в сотне архивов, чтобы найти, откуда можно будет восстановить нужный файл).

    Я ей не особо пользовался, только запускал пару раз, чтобы понять для чего и как она используется.

    Единственное, что я, возможно, не советовал бы: использовать её в качестве production-решения, поскольку я частенько в списках рассылки встречал сообщения о том, что файл в котором она хранит индексы бьётся, что, впрочем, никак не влияет на сохранность самих данных.

    Также в комплекте с dar идёт dar_static: статически скомпилированый бинарник, который никогда не будет лишним положить рядом с архивами.

    Важное замечание



    Поскольку утилита достаточно активно разрабатывается, у неё есть периодически возникающие проблемы (которые оперативно решаются в списке рассылки), и в связи с этим в дистрибутивах почти всегда присутствует неактуальная версия dar. Например в Ubuntu 12.04 используется, если не ошибаюсь dar версии 2.4.2, которая не может создать/восстановить архив в некоторых специфичных условиях. С dar версии 2.4.12 лично у меня никаких проблем нет.

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

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

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

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

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

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

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

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

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

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

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

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

                                                  После окончания второй недели идёт неделя декремента: d- d- d- d- d- d- f и после снова инкременты. Худший исход для такой схемы — потеря полного бэкапа
                                                  • 0
                                                    Таким образом, по вашей схеме, при порче f бэкапа мы точно также потеряем 2 недели бэкапов (худший исход), как и в случае тупо инкрементальных бэкапов. И всё так же не понятен тайный смысл d бэкапа, почему не делать только f и i?
                                                    Если я туплю — ткните где, плиз =)
                                                    • 0
                                                      А! Кажись понял. Просто у вас в точке перехода ...+i d-… (декрементальный бэкап от инкрементального — мама-мия) по-сути формируется full бэкап. Тогда да, максимум можно потерять 1 неделю. Но тогда сравнение с 2 неделями инкрементального всё-таки не совсем корректно. Такую схему надо сравнивать с f i i i i i f i i i i i i, а в ней худший исход также 1 неделя.
                                                      В общем, что-то не сходится у вас ;)
                                                      • 0
                                                        Ну две серии инкреметальных это два полных бэкапа, отсюда экономия места.

                                                        Декреметальных хорош, когда часто нужен только последний, и чтобы не восстанавливать полседовательно серию бэкапов можно восстановить только один.
                                                • 0
                                                  Возможность сделать избыточность — хорошо, но это уже чуть другая тема, всё таки.
                                              • +2
                                                Вопрос к знатокам — насколько быстрый этот архиватор, если брать с индексом? К примеру, если заархивировано 5 миллионов мелких файлов, как быстро можно извлечь 1-2 случайных? Гуглил бенчмарки, ничего не нашел.
                                                • 0
                                                  Индекс для того и существует, чтобы делать вытаскивание файлов моментальным. Открыл файл, прочитал индекс, узнал смещение, перешёл по нему, прочитал файл, закрыл файл.
                                                  • +2
                                                    Это да, но одно дело теория, а другое — практика… Если реализовано все не очень хорошо, то и скорость может быть соответствующая.
                                                    • 0
                                                      Ну я проверял всё это (читал код + смотрел в strace)
                                                • 0
                                                  разобрался.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.