Ещё один формат хранения архивов: 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
                                                  разобрался.

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