Restic: Данные из неполного снимка.

Ах, хм. Вам нужен конкретный файл или просто «все данные»? Данные есть, и у restic есть все средства, чтобы их вытащить, но это будет означать либо создание сценария вокруг restic (что будет очень медленно), либо добавление собственного кода для restic.

Честный вопрос: насколько важны для вас данные? Я мог бы потратить некоторое время сегодня на то, чтобы что-то вместе для вас подготовить, что должно дать вам доступ почти ко всем данным, которые были загружены в репозиторий, но это, вероятно, не так «готово к производству», как большая часть кода. :)

Эти данные очень важны для меня, и, к сожалению, другой копии нет. Я знаю, что это не идеально, но я пытался решить эту проблему. Я занимаюсь исправлением оборудования, чтобы попытаться вернуть том в оперативный режим, но на данный момент это не выглядит слишком обнадеживающим. Если бы у меня был способ указать каталог и иметь возможность получать доступ и загружать все, что находится внутри этого каталога, это было бы серьезным спасением. Это много данных (большая часть - видеопроекты), поэтому более быстрый вариант будет предпочтительнее. При этом я действительно не знаю, сколько потребуется работы, и я ценю, что это бесплатное программное обеспечение, но я был бы чрезвычайно благодарен, если бы это стало возможным.

хорошо, я посмотрю, что я могу сделать.

Огромное спасибо.

Вы можете начать с запуска restic rebuild-index , чтобы у нас был свежий индекс, охватывающий все пакеты в репо.

Приступим к этому сейчас.

Вау, это очень великодушно с твоей стороны @ fd0.

Если я могу помочь с тестированием чего-либо, связанного с этим, дайте мне знать.

Должен ли restic rebuild-index запрашивать у меня пароль репо? Пока еще нет. Я подозреваю, что это может занять довольно много времени из-за количества данных в репо. Я вполне доволен, что он будет работать все выходные или, если необходимо, до следующей недели. Я просто хочу быть уверенным, что мне не нужен пароль, прежде чем я оставлю его без присмотра на долгое время.

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

На раннем этапе он должен напечатать что-то вроде этого:

repository ed6136ad opened successfully, password is correct

По крайней мере, при интерактивном запуске (без перенаправления stdout в файл журнала).

Вы также можете пропустить rebuild-index если последние 15 минут загруженных данных не так важны, мы всегда можем сделать это позже.

У меня нет этого набора переменных окружения RESTIC_PASSWORD , но я установлю его и просто позволю команде запуститься. Примерно 10 минут он ничего не возвращал, поэтому я поставил ему ctrl-c и попробовал снова. У меня правильный синтаксис, правда? restic -r b2:MY_BUCKET_NAME:/ rebuild-index В любом случае данные за последние 15 минут должны быть очень маленькими по сравнению с общими выгруженными данными, поэтому я буду счастлив вернуться к этому позже.

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

Я отправил коммит в ветку recover-data , просто создайте restic ( go run build.go ) и назовите его так:

$ restic -r b2:MY_BUCKET_NAME:/ recover

Затем он должен перечислить все деревья в репо, найти корневые деревья и создать новый моментальный снимок, ссылающийся на все корневые деревья:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

Затем у вас есть снимок (в данном случае 26f25bf1 ), который вы можете восстановить, или просто используйте restic mount чтобы просмотреть его. Вы также можете просто перечислить его:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

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

Дайте мне знать, если это вам поможет!

Итак, чтобы добавить немного предыстории: я прочитал выпуск github, затем пошел в душ и подумал про себя: «Хм, это не так уж сложно». Оказывается, я был прав, и это не так. Если эта функция будет полезна другим, мы сможем превратить ее в подходящую команду позже, но пока я надеюсь, что она работает для вас, и вы можете получить доступ к данным, которые уже загружены в B2.

Сколько было данных? Насколько вы поправились?

Удачи!

Вот Это Да! Это было быстро! Спасибо огромное! Я только что клонировал репо и сейчас попытаюсь его построить. Я также понял, почему не работает rebuild-index. Это была проблема с DNS в сети, в которой находится наш сервер. Я исправил это и получил Fatal: unable to create lock in backend: repository is already locked by PID 41208 так что, очевидно, моя загрузка не была остановлена ​​изящно. Команда unlock кажется, очистила это, и в настоящее время выполняется rebuild-index.

Я сделаю все возможное сегодня, но я уезжаю в северный Мичиган на выходные примерно через 15 минут, и я не думаю, что у меня там будет хороший доступ в Интернет. Я вернусь к этому в понедельник, и я дам вам более подробную информацию :-)

Спасибо тебе большое за это! Извините, что оставил вас висеть, но я свяжусь с вами в понедельник.

Если эта функция будет полезна другим, мы можем превратить ее в подходящую команду позже.

Я хотел бы помочь с этим любым возможным способом. Моя скорость загрузки составляет 1 Мбит / с, поэтому первоначальное резервное копирование может занять до 3-6 месяцев. Возможность восстановления до завершения будет отличной функцией, особенно если это не так уж сложно, как вы говорите. Дайте мне знать, чем я могу быть полезен! Большое спасибо за работу над этим! : D

Кроме того, я думаю, что ваше решение довольно гениальное. Элегантно и довольно просто.

Извините, что оставил вас висеть, но я свяжусь с вами в понедельник.

Не беспокойтесь об этом, мне просто интересно, сработает ли это: солнцезащитные очки:

Данные в B2 в безопасности и никуда не денутся. Даже команда recover не изменит никаких данных, она просто прочитает их, добавит еще один файл и снимок, и все.

Итак, чтобы дать вам немного предыстории (возможно, я расширю это до сообщения в блоге позже): внутри репозиторий restic содержатся файлы разных типов, например snapshot и data files:

• data файлы содержат кучу более коротких tree или data blobs, с заголовком в конце, описывающим, что находится в файле и где именно
• snapshot files содержат только крошечный документ JSON, описывающий снимок, который ссылается на tree

Когда файл сохраняется с restic, он разрезается на data blobs, которые собираются и сохраняются вместе в одном или нескольких файлах в репозитории. Имя файла вместе со списком ссылок (идентификаторов) на блобы data затем сохраняется в виде дерева. Когда restic завершается архивирование каталога, список файлов (имена и ссылки для data blobs) сохраняется как blob tree в другой файл data .

Для подкаталогов restic сохраняет имя подкаталога вместе со ссылкой на блоб tree описывающий содержимое в другом tree .

В конце выполнения restic backup у нас есть корень tree который не ссылается никакое другое дерево, но который содержит все ссылки на все деревья верхнего уровня и, следовательно, (косвенно) на все файлы и подкаталоги в резервной копии. На последнем этапе restic создает новый файл snapshot который ссылается на корень tree .

Если вы укажете restic забыть конкретный снимок, на корневое дерево больше не будет ссылаться. restic prune обнаруживает это и удаляет дерево и все другие ненужные tree и data blobs.

В общем, tree сохраняется в репозитории только тогда, когда все файлы и подкаталоги в нем были успешно сохранены. Итак, как только появляется blob tree , мы можем предположить, что данные, на которые он ссылается (включая подкаталоги), также присутствуют.

Когда restic прерывается во время резервного копирования, в репо будет группа из tree blobs вместе с данными в файлах, на которые они ссылаются. Итак, для восстановления данных restic нужно только сделать следующее:

• составьте список всех идентификаторов деревьев, отметьте, на какие деревья ссылались (изначально: нет)
• для каждого дерева:
  
  
  
  • загрузить дерево
  
  
  • для каждой записи в дереве:
    
    
    
    
    
    • если это каталог, он ссылается на другое дерево, отметьте это дерево как указанное в списке
    
    
    
  
  

Затем снова просмотрите список деревьев, выбросьте все, на которые мы видели ссылки. Остальные деревья являются корневыми деревьями, что означает либо деревья, на которые (или были) непосредственно ссылаются моментальный снимок, либо которые «болтаются» в результате прерванного выполнения restic backup .

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

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

Прежде чем объединить это с мастером, я думаю, нам следует сделать следующее:

• Добавьте параметр в recover который исключает корневые деревья, на которые ссылаются существующие снимки состояния, поэтому мы получаем только действительно болтающиеся корневые деревья. Может быть, это поведение должно быть даже по умолчанию, большинство пользователей, вероятно, не слишком заинтересованы в данных, к которым они могут получить доступ через существующие снимки…
• Также сделайте доступными в новом снимке объекты data ссылок, чтобы пользователи могли собирать вместе части файлов, которые еще не были включены в объект tree .
• Установите разумные метаданные как для нового дерева, так и для нового снимка. На данный момент это очень некрасиво (достаточно, чтобы оно работало).
• Лучшая отчетность о прогрессе, сейчас это очень взломано

Небольшое обновление по этому поводу: я начал rebuild-index перед отъездом в прошлый четверг. Это умерло до того, как я вернулся с read: connection reset by peer . Я перезапустил его вчера с большим количеством параллельных подключений к b2, и, похоже, он работает нормально. Сейчас он составляет всего 5%, но я думаю, что это займет некоторое время. В ведре b2 около 90 ТБ, а в каталогах, которые я создавал, вероятно, было около 110–120 ТБ.

Честно говоря, я очень впечатлен тем, что рестик оставался таким стабильным во время загрузки. Я попробовал морошку для Mac перед тем, как попробовать отдохнуть, и мне не удалось заставить его работать с таким большим объемом данных. Я использую restic для резервного копирования своего ноутбука дома, и мне это нравится, поэтому я подумал, что попробую для этого. Поскольку я даже не завершил свою первоначальную загрузку, я понятия не имею, как пойдет что-то вроде prune , но я буду рад держать вас в курсе, если вам нужны данные о том, как restic ведет себя с большими объемами данных. . Если мне удастся заставить его выполнять все операции, необходимые для еженедельного резервного копирования, менее чем за неделю, я думаю, это будет отличным кандидатом для обработки этих резервных копий.

В настоящее время у меня есть несколько вопросов: следует ли мне дать этому rebuild-index работать до завершения, прежде чем я попробую recover ? Я что-нибудь потеряю, если не потеряю? Я думал об этом и думаю, что хотел бы восстановить как можно больше с первого раза, если это возможно, поскольку для работы с таким большим recover данных требуется время, но если лучше это убить, запустите rebuild-index позже, я могу это сделать. Будет ли запуск rebuild-index или recover с флагом --quiet ускорить работу, как это происходит с командой backup ?

Ладно, круто! Я бы порекомендовал сделать следующее:

• Прервать rebuild-index
• Запустить restic recover
• Посмотрите, какие данные содержит только что созданный снимок

Если вы хотите попробовать, вы можете снова запустить rebuild-index и очистить оставшиеся мегабайты данных из репо. Вероятно, это будет меньше нескольких сотен мегабайт, и, вероятно, это не покажет никаких новых данных, еще не содержащихся в снимке. Но можно попробовать :)

Пока rebuild-index запущен, вы не можете получить доступ к репозиторию.

Будет ли запуск rebuild-index или recovery с флагом --quiet ускорить работу, как с командой резервного копирования?

Нет.

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

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

Есть ли простой способ узнать, сколько данных нужно будет загрузить для этой операции, или способ уменьшить объем загружаемых данных?

Кроме того, если я хочу освободить это дисковое пространство, restic cache --cleanup способ сделать это?

Нет, это удаляет только каталоги кеша, которые не использовались в течение 30 дней. Просто удалите каталог кеша, который должен находиться где-то в вашем домашнем каталоге.

Какую команду вы точно запускали? И rebuild-index и recover не должны сохранять много данных на жестком диске, за исключением кеша метаданных ...

Сейчас не за моим столом. но это было что-то вроде: ./restic -o b2.connections=x -r b2:mybucket:/ recover Я думаю, что x установлен на что-то огромное. Возможно, это было частью проблемы. Я могу перезапустить его без бита -o b2.connections=x . Я нашел каталог кеша и удалил его.

Во-первых, отличный инструмент.
Мне также нужно сделать резервную копию терабайтов данных через медленное соединение, и есть шанс, что резервное копирование не удастся, хотя оно еще не завершено. Есть ли рекомендуемый способ резервного копирования только нескольких файлов за раз?

Есть ли рекомендуемый способ резервного копирования только нескольких файлов за раз?

Что обычно работает (я слышал), так это сохранение отдельных частей исходных данных (например, отдельных каталогов), а когда это завершается, сохранение всех каталогов вместе. Когда исходные данные не изменились, restic не должен загружать почти ничего из-за встроенной дедупликации.

Лучшим местом для таких вопросов был бы форум https://forum.restic.net , там вопрос (и ответы!) Найти гораздо легче.

@pauletg , как все прошло?

Я предложил новую команду recover в # 2056.

Со времени моего последнего поста я не сильно продвинулся в восстановлении после отдыха. Хорошая новость в том, что нам удалось оживить сервер, и данные не пострадали в результате сбоя, поэтому у меня есть свои данные. Команда восстановления, кажется, заполняет жесткий диск моей машины, прежде чем она могла быть завершена. Это могло быть вызвано несколькими факторами: моя резервная копия была огромной, и я использовал большое количество подключений к b2 для загрузки, а HD на машине, которую я использовал для восстановления, был относительно небольшим. Я уверен, что, вероятно, было бы здорово, если бы размер моей резервной копии был более разумным. Дайте мне знать, если есть дополнительная информация, которая будет вам полезна. Я очень ценю, что вы работаете над этим, и наличие этой функции, доступной для резервного копирования моего ноутбука, действительно приятно.

Спасибо за ответ! Если хотите (и у вас много времени), вы можете повторить попытку с помощью --no-cache , но это займет еще больше времени. Я закрою эту проблему, когда # 2056 будет объединен.

Пожалуйста, дайте нам знать, если у вас есть дополнительные отзывы! :)