0,0
рейтинг
12 марта 2014 в 18:42

Администрирование → Ещё один формат хранения архивов: 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 ввиду изменения формата архива.
Менькович Никита @librarian
карма
88,4
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (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
      tar как раз архиватор (а также ar, cpio и т.п.). А вот всякие bzip2, gzip и т.п. — это компрессоры. Так было сотни лет до нашей эры, со временем же для обывателя потерялась разница между терминами архиватор и компрессор, и теперь архиваторы умеют и сжимать прозрачно.
    • +3
      Не путайте архивацию и сжатие!!!
      • +3
        Спасибо! Если честно не знал о таком нюансе. Иногда в комментах на хабре полезное пишут! ;)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      There's xkcd of it. No exceptions.
  • +4
    Давно пользуюсь, всё ок.
  • +2
    tar пилят уж лет 30 и до сих пор находят баги. Мелкие, но всё же баги. Интересно сколько потребуется времени, чтобы dar стал поистине стабильным.
    • +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
    разобрался.

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