Restic: обрабатывать крупный чернослив намного эффективнее

С производительностью для восстановления больших репозиториев/репозиториев с большими файлами, которые теперь разрешены веткой вне очереди @ifedorenko , похоже, что это следующий валун для использования restic в многотерабайтных средах, где репо не находится на локальном компьютере. диск и не доступен через REST-сервер на петлевом интерфейсе.

В настоящее время пустая обрезка (удаление моментального снимка, который на 100 % идентичен предыдущему снимку) по сравнению с репозиторием в локальной корзине S3 в зоне доступности на высокопроизводительных инстансах AWS с теоретической пропускной способностью 10 Гбит/с выполняется со скоростью:

1) создание нового индекса -- ~160 пакетов в секунду
2) поиск данных, которые все еще используются — всего 56 секунд
3) перезапись пакетов -- ~3 пакета в секунду

160 пакетов в секунду — это медленно, но все же терпимо (~ 80 минут работы против репозитория на 3 ТБ).

Но перезапись @ 3 пакета в секунду будет работать почти 10 часов, даже для моего noop prune (удалит 0 пакетов и перезапишет 111098 пакетов, это освободит 180,699 ГиБ). Для значимого сокращения большого репо вы замораживаете новые резервные копии на 24+ часа.

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

Лично я бы не стал тратить время на оптимизацию текущей реализации блокирующего сокращения, я думаю, что неблокирующее сокращение является лучшим долгосрочным решением.

Я недавно работал над этим. Вот что я сделал:

• Загрузите существующий индекс вместо сканирования всех пакетов (а затем просмотрите все пакеты, которых не было в индексе)
• Параллельное сканирование моментальных снимков на наличие используемых BLOB-объектов.
• Параллельная перезапись частично используемых пакетов
• Запишите новый индекс, используя информацию индекса, уже находящуюся в памяти.

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

Вот некоторые цифры производительности (с использованием репозитория с 875 ГиБ данных, около 180 000 пакетов и 36 снимков, с использованием сервера loopback rest в качестве бэкэнда):

• Текущий код:
  
  
  
  • 35-40 минут (каждому) для построения индекса в начале и конце обрезки (всего 70-80 минут)
  
  
  • 4-5 минут, чтобы найти использованные блобы
  
  
  • Несколько секунд, чтобы перезаписать частично использованные пакеты
  
  
• Мои изменения на данный момент:
  
  
  
  • Несколько секунд для загрузки существующего индекса (несколько больше, если нужно сканировать неиндексированные пакеты)
  
  
  • Менее 2 минут на поиск использованных BLOB-объектов
  
  
  • Несколько секунд для записи нового индекса
  
  

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

Кортни:

Звучит супер многообещающе! Хотели подтвердить, что это именно та ветка, в которой вы работаете? Я рад испытать.

https://github.com/cbane/restic/tree/prune-агрессивный

Нет, эта ветка является частью форка основного репозитория. Я еще не публиковал свои изменения. Через несколько дней я смогу отправить свою незавершенную версию на GitHub, чтобы вы могли ее опробовать.

Хорошо, у меня есть версия, которая должна быть готова для опробования другими людьми. Это в этой ветке: https://github.com/cbane/restic/tree/prune-speedup

Текущие ограничения:

• Я не реализовал автоматическую настройку количества воркеров репака. А пока задайте для переменной среды RESTIC_REPACK_WORKERS количество рабочих процессов, которые вы хотите использовать. По умолчанию это значение равно 4, если оно не установлено.
• Мне нужно поработать над обработкой ошибок при перепаковке. Я не внес никаких реальных изменений в существующую однопоточную перепаковку; Мне нужно просмотреть различные случаи ошибок и убедиться, что параллельная переупаковка не вызывает никаких проблем.

Это выглядит потрясающе. Спасибо вам за вашу работу!

Я немного протестировал это с копией репозитория объемом 3 ТБ + в Amazon S3, и пока это выглядит потрясающе. Обрезка переупаковки, которая заняла бы недели, теперь выполняется менее чем за час, и при этом используется относительно медленный EBS в качестве временного пространства.

Здесь настоящий переломный момент! Отличная работа, @cbane!

Эй, я понял, что ошибся во времени.

Одной областью, которая по-прежнему является однопоточной и выглядит так, как будто распараллеливание может принести пользу, является этап «проверка пакетов, отсутствующих в индексе», который все еще может занять 3-4 часа в репозиториях с несколькими терабайтами, но это все еще массивно, огромное улучшение, спасибо!

@cbane Я не смог создать проблему против вашего форка, поэтому дайте мне знать, если есть лучшее место для этого.

Во время другого тестового прогона репак провалился в самом конце (переписав последний пак), работая с 32 воркерами:

found 1396709 of 2257203 data blobs still in use, removing 860494 blobs
will remove 0 invalid files
will delete 119301 packs and rewrite 88485 packs, this frees 896.269 GiB
using 32 repack workers
Save(<data/c136027b25>) returned error, retrying after 723.31998ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
Save(<data/09d4692900>) returned error, retrying after 538.771816ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx. Retry again.
Save(<data/23d0d4f842>) returned error, retrying after 617.601934ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
[10:02] 100.00%  88484 / 88485 packs rewritten
panic: reporting in a non-running Progress

goroutine 386596 [running]:
github.com/restic/restic/internal/restic.(*Progress).Report(0xc42011c2c0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0)
        internal/restic/progress.go:122 +0x242
github.com/restic/restic/internal/repository.Repack.func2(0x8, 0xe17f58)
        internal/repository/repack.go:66 +0x136
github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1(0xc4389246c0, 0xc56f509160)
        vendor/golang.org/x/sync/errgroup/errgroup.go:57 +0x57
created by github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go
        vendor/golang.org/x/sync/errgroup/errgroup.go:54 +0x66

У меня есть новая версия, в той же ветке, что и раньше. Я также перебазировался против master .

Вот основные изменения по сравнению с предыдущей версией:

• Преобразована переупаковка: теперь каждый рабочий выполняет все этапы переупаковки одной упаковки в конвейер.
• Исправлен сообщенный сбой в конце перепаковки.
• Переупаковка теперь автоматически масштабирует количество рабочих для этапов конвейера в зависимости от количества ЦП и настроенного лимита подключений для серверной части. (Переменная окружения RESTIC_REPACK_WORKERS больше не используется.)
• Незначительные изменения в поиске использованных BLOB-объектов.
• Распараллелено сканирование неизвестных пакетов.

Я все еще хочу поработать над поиском использованных BLOB-объектов. В настоящее время каждый снимок обрабатывается одним рабочим. Это может оставить ресурсы ЦП неиспользованными, если моментальных снимков меньше, чем ЦП, или если между моментальными снимками существуют значительные различия в размерах. Я хотел бы, чтобы он распределял обработку поддеревьев между разными работниками; Я думаю, что знаю, как это сделать, мне просто нужно это реализовать.

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

Только что протестировано. Это устраняет сбой в конце перепаковки и работает очень, очень хорошо.

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

Это особенно сильно укусит во время первой обрезки репозитория, который ранее не мог быть сокращен, поскольку есть _lot_ пакетов, которые необходимо удалить.

Однако даже при однопоточном удалении ежедневное удаление/удаление репозитория пакетов размером 1,7 ТБ и 356 000, который перезаписывает пакеты размером 14,7 000 и удаляет пакеты размером 33 000, теперь занимает чуть менее 20 минут.
Раньше вообще нельзя было обрезать.

Отличная работа, спасибо!

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

Я планирую открыть запрос на это в ближайшее время, предполагая, что ничего не сломалось. (Однако сначала я подчищу историю.) @fd0 , хочешь сначала взглянуть на это?

Отлично сработал в нашем тестовом прогоне. Переписал 30к паков за 225 секунд, удалил 73к паков за 50 секунд.

Общее время работы с репозиторием объемом 1,74 ТБ в S3 с 32 сохранившимися снимками составило чуть более 6 минут.

Блестящая работа.

@cbane Я пробовал вашу ветку https://github.com/cbane/restic/tree/prune-speedup

но это ошибка, которую я получаю :(

root<strong i="9">@srv</strong> ~/restic-backups # restic --no-cache prune
repository 49b87c6a opened successfully, password is correct
listing files in repo
loading index for repo
[0:28] 1.01%  30 / 2982 index files
pack cbbebd8d already present in the index
github.com/restic/restic/internal/index.(*Index).AddPack
    internal/index/index.go:266
github.com/restic/restic/internal/index.Load.func1
    internal/index/index.go:230
github.com/restic/restic/internal/repository.(*Repository).List.func1
    internal/repository/repository.go:640
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1.1
    internal/backend/backend_retry.go:133
github.com/restic/restic/internal/backend/rest.(*Backend).listv2
    internal/backend/rest/rest.go:423
github.com/restic/restic/internal/backend/rest.(*Backend).List
    internal/backend/rest/rest.go:358
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1
    internal/backend/backend_retry.go:127
github.com/cenkalti/backoff.RetryNotify
    vendor/github.com/cenkalti/backoff/retry.go:37
github.com/restic/restic/internal/backend.(*RetryBackend).retry
    internal/backend/backend_retry.go:36
github.com/restic/restic/internal/backend.(*RetryBackend).List
    internal/backend/backend_retry.go:126
github.com/restic/restic/internal/repository.(*Repository).List
    internal/repository/repository.go:634
github.com/restic/restic/internal/index.Load
    internal/index/index.go:202
main.pruneRepository
    cmd/restic/cmd_prune.go:202
main.runPrune
    cmd/restic/cmd_prune.go:128
main.glob..func18
    cmd/restic/cmd_prune.go:28
github.com/spf13/cobra.(*Command).execute
    vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
    vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
    vendor/github.com/spf13/cobra/command.go:800
main.main
    cmd/restic/main.go:86
runtime.main
    /snap/go/3947/src/runtime/proc.go:200
runtime.goexit
    /snap/go/3947/src/runtime/asm_amd64.s:1337

@antetna Похоже, в вашем репозитории есть несколько индексных файлов, которые охватывают одни и те же пакеты. Я не знаю, как это может произойти, но я добавил тестовый пример для этого в набор тестов и могу воспроизвести вашу ошибку. Я буду работать над его исправлением.

@antetna Хорошо, я только что отправил новую версию в ту же ветку (не перемотал вперед), которая работает с моим тестовым примером дублирующегося индекса. Не могли бы вы попробовать?

Я планирую в ближайшее время открыть пул-реквест с текущей версией этой ветки, если кто-то еще не заметит каких-либо проблем.

Большое спасибо @cbane! Стандартная обрезка заняла около 55 часов, чтобы удалить мой репозиторий с 12000+ моментальными снимками ~860 ГБ. Благодаря вашему более агрессивному параллельному подходу время сократилось до чуть более 3 часов.

Привет @cbane , потрясающая работа!

Запустив этот PR здесь на Debian 9 amd64, скомпилированном с Go 1.12.1, получаю следующую ошибку после 220 минут работы в моем репозитории объемом 30 ТБ:

checking for packs not in index
[0:52] 16.45%  178 / 1082 packs
[5:23] 100.00%  1082 / 1082 packs
repository contains 3213929 packs (259446787 blobs) with 15.025 TiB
processed 259446787 blobs: 30090 duplicate blobs, 4.906 GiB duplicate
load all snapshots
find data that is still in use for 3 snapshots
[0:04] 0.00%  0 / 3 snapshots
tree 6f144a19eaae0e81518b396bfdfc9dd5c6c035bdba28c6a90d6f70e692aa1c55 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
        internal/repository/repository.go:707
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:52
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func4
        internal/restic/find.go:89
gopkg.in/tomb%2ev2.(*Tomb).run
        vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1337

Как мне от этого оправиться?

Спасибо,
-- Дурваль.

@DurvalMenezes Похоже, в вашем репозитории отсутствуют некоторые файлы пакетов. Вы обрезали его раньше? Удалось ли restic check ? Если это не так, это должно дать вам более подробное представление о том, что не так.

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

Спасибо за ответ, @cbane. Подробнее, ниже:

Вы обрезали его раньше?

Нет, это мой первый чернослив. Короче говоря: в моем репозитории ~ 95 снимков из 3 локальных грязей на моем NAS; эти 3 грязных дерева составляют ~ 30 ТБ и ~ 60 М файлов / подкаталогов, и для резервного копирования требуется все больше и больше времени, до такой степени, что резервное копирование всего 24 часов новых данных (менее 10 ГБ) занимало более 24 часов. Совет на форуме состоял в том, чтобы запустить restic forget (что я и сделал, оставив только последние 3 снимка), а затем restic prune , что я сделал сначала с помощью restic 0.9.5 (но он прервался после ~ 24 часа из-за OOM). Затем я обновил машину (виртуальную машину в Google Compute Cloud) до удвоенного объема ОЗУ, а затем использовал ваш PR, что дало указанную выше ошибку.

Рестичная проверка прошла успешно? Если это не так, это должно дать вам более подробное представление о том, что не так.

Я запускаю restic check за последние 90 часов (также используя ваш PR), и до сих пор это дало мне этот вывод: restic-check-PARTIAL_output.txt

Как указано в конце приведенного выше файла, restic check отобразил свое последнее сообщение («проверить снимки, деревья и капли») более 3 дней назад... Я начинаю задаваться вопросом, что оно застряло и никогда не закончится. :-/ На самом деле, "strace" процесса показывает, что он снова и снова открывает один и тот же файл локального кеша:

``дата; strace -t -f -p 2608 -e openat 2>&1 | grep открыть | egrep -v незавершенное\|возобновлено | голова
Вт 23 июля 00:41:59 UTC 2019
[Pid 26508] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2608] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2615] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2615] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2608] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 11
[Pid 2638] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2638] 00:41:59 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

Вт, 23 июля, 10:14:27 UTC 2019
[Pid 2632] 10:14:27 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2639] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2613] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2617] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2611] 10:14:28 openat (AT_FDCWD "/ TMP / restic-регистрация кэш-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / данные / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
```

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

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

Еще раз спасибо,
-- Дурваль.

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

Я не трогал код rebuild-index , поэтому вы можете сделать это с любой версией.

@cbane , просто чтобы держать вас в курсе: я начал restic rebuild-index , используя ваш PR 5 дней назад (я понимаю, что подойдет любая версия, но использование вашей делает все проще), и с тех пор он работает. После первых нескольких безнадежных дней (когда экстраполяция из процентов, казалось, указывала на то, что он будет работать более 30 дней), он, похоже, набрал некоторую скорость и должен работать «всего» еще 10 дней или около того (по крайней мере, в его нынешнем состоянии). этап «подсчет файлов в репо»).

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

Держим всех в курсе: мой бесплатный кредит GCloud на 300 долларов закончился, полностью поглощенный 104-гигабайтной виртуальной машиной, которую мне пришлось создать для запуска prune (и, я полагаю, также rebuild-index ). У меня заканчиваются варианты :-/ Обновлю, когда/если найду выход из этой неразберихи.

Я попробовал ветку "prune-speedup" и результаты очень многообещающие!

Серверная часть: S3

# bin/restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
# bin/restic prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[1:30:34] 100.00%  319784 / 319784 packs
repository contains 319784 packs (5554019 blobs) with 1.445 TiB
processed 5554019 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 30 snapshots
[3:38:52] 100.00%  30 / 30 snapshots
found 5376708 of 5554019 data blobs still in use, removing 177311 blobs
will remove 0 invalid files
will delete 3526 packs and rewrite 4850 packs, this frees 26.925 GiB
[1:28:21] 100.00%  4850 / 4850 packs rewritten
counting files in repo
[1:20:27] 100.00%  314240 / 314240 packs
finding old index files
saved new indexes as [b7029105 797145b1 0ed8981e 7f19c455 dff4d9be a52d8e7a 0cf9f266 ab32a9e4 f34331b3 84c84cbb 563896c9 9902e35d 817ef96c 6b4dcfef 32d3e18c 1d782d96 b12554dd d4b69bcf 8ec94a43 66cbd035 8e9cb96d d74b5246 ca7d7ca3 1f209708 9fe26189 28414ee2 88ff07fb 24280466 8757a1f9 8706ff35 5fab942b 549409c3 f781a762 9417afec 4b2361aa 6b43f992 8da8dfe7 54ec498e 5be6fb8a 17411b83 270f3ce3 ba520d35 95913ad0 f8f15108 cbc67971 a419ff7c 875cfcc7 13f55ece bd488aa4 7f5b588a cddd40b4 7a79d1ce bd7e3d0f 2cdcd635 ee6e28c3 98146287 50867bde 41a056ae 836ce971 e9451c8b 0f9cc7e6 52dedc04 c4e8e7f6 2e4966f0 ba4fa5b3 ddc9a766 b995fd36 fd6b3ac8 1c12bcc3 4c98c3c9 39ac7cd5 42ebf4c1 1a48465e b5245192 73a73c5e daa6ee8d d26ce697 9f84d9b3 bc371def b141466a 6906b3c1 282ce115 d8024363 10f0b924 ad4fad64 9450aada 31378365 65d785b3 98b085d0 768f420c f22512b3 be3223ba 031d5488 f2b7fcf6 87177471 fd269664 b239b89e 6bf972ea 0d6f8f36 87362542 fff9c2cd 5c85ac76 f91daae1 dc594a83 220bdc83]
remove 1459 old index files
[2:33] 100.00%  8376 / 8376 packs deleted
done
# 

Теперь с версией для разработчиков:

# bin/restic_linux_amd64 version
restic 0.9.5-dev (compiled manually) compiled with go1.12.4 on linux/amd64
# bin/restic_linux_amd64 prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[57:21] 100.00%  314240 / 314240 packs
repository contains 314240 packs (5376708 blobs) with 1.419 TiB
processed 5376708 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 29 snapshots
[1:48:18] 100.00%  29 / 29 snapshots
found 5356653 of 5376708 data blobs still in use, removing 20055 blobs
will remove 0 invalid files
will delete 212 packs and rewrite 1427 packs, this frees 3.114 GiB
[14:16] 100.00%  1427 / 1427 packs rewritten
counting files in repo
[57:47] 100.00%  313618 / 313618 packs
finding old index files
saved new indexes as [004d6eb2 630de131 1b85faed 0fb7a978 bc500e05 34f7d187 447c3b59 ada047d2 5430430e 768f606e a5c341ea a75059c5 71d0fbec c63f5c56 ba43e69d f47699f5 d7cd2587 5826bcae 6250ec67 6af77aa4 cbf8c1f9 a7809b5f c3242748 8bb7d037 8ca69481 5a8877c3 fb30ea48 4bdb6269 eeeba466 7cdc444a bc15ddd5 c5544612 b8a5004c 2879403a c33778b7 e692013a 41ce8a1d 55b4be0a 5714b820 1adca569 b06ccd6b 16467da7 79ed066a 64c7e397 43217ede af7350a4 73c65a0f 35260990 a232ea42 c843bfa5 332aded7 0e294517 26984755 3c36a14b 68b2024e 267bf0b2 a41c4f64 aa46affb c7a6e2ac 0d34c60f 766d21f0 0d7b8b41 4fea4363 a1a3c5cd 73809a0e 56a67410 25314d47 a32ded24 68feae36 78ef5cbb b051a740 6a51f900 d2ee860f 1ad44787 c6c4358d 89de2f69 a157bd2b 77995b94 3bc58934 b905be42 0a1df2e7 ba67a98c 263b5266 7a809abc 34ff6f07 d96adc12 8f69fc74 ebb053eb 8fb68f6a 11224e7d 990f61f8 764941fc ed95513b 1c17c8aa 3226a7cb 76988c78 e4d8f156 b4d4c952 8c379d51 e968f3c9 f9cfff55 464cf3e1 f9d23c32 136957e3 02e397b1]
remove 105 old index files
[0:32] 100.00%  1639 / 1639 packs deleted
done
#

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

@fbarbeira Судя по тому, что вы опубликовали, вы на самом деле не используете мою улучшенную версию. Вот результат, который я получаю, когда сокращаю свой большой репозиторий на Backblaze B2:

repository 399dfab1 opened successfully, password is correct
listing files in repo
loading index for repo
[0:02] 100.00%  71 / 71 index files
checking for packs not in index
repository contains 208840 packs (1675252 blobs) with 1006.203 GiB
processed 1675252 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 32 snapshots
[0:16] 100.00%  32 / 32 snapshots
found 1675113 of 1675252 data blobs still in use, removing 139 blobs
will remove 0 invalid files
will delete 4 packs and rewrite 24 packs, this frees 26.404 MiB
[3:31] 100.00%  24 / 24 packs rewritten
saving new index
[10:31] 70 index files
remove 71 old index files
[0:04] 100.00%  28 / 28 packs deleted
done

Основным источником медлительности в этом является ограниченная скорость загрузки через мой кабельный модем.

Вывод restic version также должен выглядеть примерно так:

restic 0.9.5 (v0.9.5-31-g09b92d6d) compiled with go1.11.6 on linux/amd64

Есть ли намерения объединить это обновление @fd0 ?

Я был бы очень признателен за то, чтобы это улучшение также стало официальным релизом. Ротация резервных копий стала настолько медленной, что, к сожалению, Restic больше не является вариантом.

@cbane , один элемент, который определенно не является блокировщиком, но я решил отметить: перезапись пакетов сокращения становится медленнее по мере роста репозиториев.

Например, шаг перезаписи пакетов для репозитория из 3 984 097 пакетов перезаписывает пакеты со скоростью 110 пакетов в секунду на i3.8xlarge, взаимодействуя с корзиной S3 в той же зоне доступности.

Тот же набор экземпляров + резервное хранилище с меньшим репозиторием (450 473) перезаписывается со скоростью 200 пакетов в секунду.

@pmkane , есть ли разница в скорости, даже если они переписывают одинаковое количество пакетов? Или он всегда есть, сколько бы паков ни переписывалось? Кроме того, это просто перезапись пакета, или другие этапы тоже замедляются?

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

@cbane , не уверен, что это зависит от количества пакетов или размера репо. Я могу запустить несколько тестов на дубликате нашего меньшего репо и посмотреть. С удовольствием запускаю версию с профилированием и делюсь результатами.

Ниже приведены некоторые примеры таймингов для репозитория пакетов 460k — тайминги 3,7 мм:

индекс загрузки для репо
[0:01] 100,00% 154 / 154 индексных файла

найти данные, которые все еще используются для 36 снимков
[0:34] 100,00% 36 / 36 снимков
[0:26] 100.00% Переписано 4555 / 4555 паков (175 паков в секунду)
[0:21] 151 индексный файл
[0:01] 100.00% 11401 / 11401 пакетов удалено

Репозиторий на 3 752 505 упаковок. Также стоит отметить, что использование памяти увеличивается с ~ 1 ГБ RSS до 8 ГБ RSS на этапе «найти данные, которые все еще используются для 14 снимков». Restic в конечном итоге достигает ~ 16 ГБ RSS. Возможно, это неизбежно, учитывая большой размер репо:

индекс загрузки для репо
[0:33] 100,00% 1188/1188 индексных файлов

найти данные, которые все еще используются для 14 снимков
[2:12] 100,00% 14 / 14 снимков
[49:07] 100.00% 339187 / 339187 паков переписано (115 паков/сек)
сохранение нового индекса
[10:59] 1176 индексных файлов
удалить 1188 старых индексных файлов
[4:51] 100.00% 409728 / 409728 упаковок удалено

@cbane , прошу прощения. Отвлекающий маневр на скорости обрезки — когда я выполнял независимое профилирование, я заметил, что два репозитория находились в разных зонах доступности, поэтому разница была полностью связана с разной задержкой для более удаленной зоны доступности.

В нашем большом репо (20,791 ТБ, 40 522 693 больших двоичных объекта) мы получаем следующую ошибку при сокращении на этапе «найти данные, которые все еще используются»:

дерево 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 не найдено в репозитории
github.com/restic/restic/internal/repository.(Repository).LoadTreeвнутренний/репозиторий/repository.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3внутренний/рестик/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3внутренний/рестик/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4внутренний/рестик/find.go:89gopkg.in/tomb%2ev2.( Могила).run
продавец/gopkg.in/tomb.v2/tomb.go:163
время выполнения.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

все резервные копии завершены успешно, и проверка restic не возвращает никаких ошибок.

Стоит ли здесь что-то копать, @cbane ?

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

Хм, сегодня опять такая же ошибка. Решено с помощью индекса перестроения, но я начинаю задаваться вопросом, может ли проблема быть вызвана самим сокращением. Рестичная проверка каждый раз возвращается чистой.

дерево 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 не найдено в репозитории
github.com/restic/restic/internal/repository.(Repository).LoadTreeвнутренний/репозиторий/repository.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3внутренний/рестик/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3внутренний/рестик/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4внутренний/рестик/find.go:89gopkg.in/tomb%2ev2.( Могила).run
продавец/gopkg.in/tomb.v2/tomb.go:163
время выполнения.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

Мы делаем полное восстановление один раз в неделю, чтобы проверить целостность резервной копии, в дополнение к ежедневному восстановлению точечных файлов.

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

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

К сожалению, тестирование с обрезкой акций невозможно из-за размера репозиториев.

На данный момент мы собираемся вернуться к моментальным снимкам EBS, но продолжим отслеживать эту и другие проблемы и будем рады проверить, где это имеет смысл!

Я добавил небольшой PR #2507, который должен исправить ситуацию. Я был бы признателен, если бы кто-то из вас мог провести некоторые тесты на этом...
Спасибо!

Чтение сокращенного кода — переупаковка считывает большие двоичные объекты, а затем последовательно сохраняет новые пакеты. Если вы переупаковываете по сети, это будет узким местом.

@DurvalMenezes — ваш NAS в локальной сети или через Интернет? Если в локальной сети, вы подключаетесь к нему через Wi-Fi или Ethernet?

Кажется, что легкой победой было бы распараллелить чтение больших двоичных объектов/сохранение пакетов в сети.

Отдельно я задаюсь вопросом, не будет ли лучшей стратегией вместо этого попытаться сделать обрезку инкрементальной. Что-то вроде двухэтапной коллекции ископаемых дубликатов: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Отдельно я задаюсь вопросом, не будет ли лучшей стратегией вместо этого попытаться сделать обрезку инкрементальной. Что-то вроде двухэтапной коллекции ископаемых дубликатов: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

См. #1141 для обсуждения этой темы.

Две новые команды «cleanup-index» и «cleanup-packs» из PR #2513 также должны значительно улучшить ситуацию. С помощью этих команд вы можете выполнить обрезку без переупаковки, если ваше репо в порядке.

Итак, я случайно сделал две вещи: я запускал почасовое резервное копирование 11 раз в час вместо 1, и я не запускал задание «забыть» в течение последних 384 дней или около того. У меня есть 101417 снимков. Я подумал, что было бы слишком медленно забывать/сокращать это, я думаю, что просто удалю это.

Вы можете попробовать #2718, однако улучшения для «забывания» моментальных снимков нет.
Если шаг забыть - ваша проблема, я бы посоветовал вам:

• выясните, какие моментальные снимки вы хотите сохранить, например, просмотрев свои последние журналы резервного копирования или просто создав еще одну резервную копию.
• удалите все файлы, кроме этих, вручную из каталога вашего репозитория /snapshots
• после этого запустите prune (если хотите с #2718)

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

Я действительно хочу попробовать эту ветку (или действительно хочу, чтобы она была включена в мастер). Я попытался проверить и получить

Fatal: невозможно открыть файл конфигурации: Stat: предоставленный вами идентификатор ключа доступа AWS не существует в наших записях.

Работает без проблем, используя основную сборку. Я также смог без проблем использовать ветку https://github.com/restic/restic/pull/2340 .

Я могу использовать эту ветку в смонтированном репозитории NFS, только репозиторий AWS не работает. Я понятия не имею, как устранить неполадки...

спасибо за хорошую работу несмотря ни на что

@ vtwaldo21 Какую ветку вы пробовали? Это был номер 2718?
Сообщение об ошибке указывает на то, что у вас возникли проблемы с учетными данными AWS. Это также может объяснить, почему NFS работала без проблем.

Работают ли с вашим репозиторием AWS другие команды restic?

@aawsome , я идиот, переставил номера веток / выпусков и действительно все запутал. Извините.

Филиал 2718 работал нормально (как в репозиториях AWS, так и в NFS). Я не могу однозначно сказать, было ли это быстрее или нет, так как он все еще работает.
Ветвь 2340 была той, в которой возникла проблема, и почему я был в этой ветке форума.

Branch 2340 основан на 0.9.5, поэтому немного старше, но не так уж плохо. Я делал такие простые тесты:

двоичный файл restic - это путь, только что установленный через RPM (0.9.6)

остальные снимки
[работает]
restic.2718/остальные снимки
[работает]
restic.2340/остальные снимки
Fatal: невозможно открыть файл конфигурации: Stat: предоставленный вами идентификатор ключа доступа AWS не существует в наших записях.

Поэтому, хотя ошибка подразумевает что-то с учетными данными AWS, я буквально запускаю команды подряд без каких-либо изменений переменных. Кажется, что-то еще не так с этой веткой.

Мои черносливы занимают дни для репо ~ 2 ТБ, поэтому очень заинтересованы в том, чтобы 2718 и 2340 были объединены в мастер.

@cbane большое спасибо за вашу работу! Мы только что объединили # 2718, который перерабатывает код обрезки, и я думаю, что он решает эту проблему так же, как # 2340.

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

Я разговаривал с @MichaelEischer , он упомянул, что в PR #2340 есть еще идеи, которые еще не были реализованы, поэтому я вновь открываю этот вопрос.

@cbane , вы заинтересованы в сотрудничестве с нами, чтобы объединить эти идеи в текущий код? Я вполне понимаю, если нет, то мы пройдемся по вашему пиару и сами их извлечем :)

Вчера у нас также было короткое обсуждение, и мы попытались определить, что могло пойти не так, чтобы в следующий раз мы могли сделать лучше. Некоторые моменты, которые мы определили, были:

• PR изменил очень чувствительную область в коде (сокращение, что в конечном итоге приводит к удалению данных), поэтому она требует дополнительной проверки.
• @MichaelEischer , а также @aawsome попытались просмотреть PR и сказали, что он слишком большой.
• В PR было всего два коммита, один из них заменил весь код другим, совершенно другим кодом, это очень сложно просмотреть
• В PR включено как минимум 4-5 разных идей и улучшений, что еще больше усложняет обзор.

Что-то еще я пропустил?

Насколько я вижу, изменения в cmd_prune.go с # 2340 полностью заменены # 2718 и # 2842 @aawsome . #3006 также заменяет изменения index/index.go.

Я извлек высокопараллельную реализацию обхода дерева из checker.go (см. https://github.com/MichaelEischer/restic/tree/streamtrees), которая позволяет реализовать параллельный FindUsedBlobs с несколькими дополнительные строки кода. Его также можно использовать повторно для команды копирования. Моя упомянутая ветвь также объединяет код, используемый для распараллеливания загрузки индекса и моментального снимка. Я разделю ветку на более мелкие PR.

Это, похоже, оставляет использование счетчика внутренних подключений и GOMAXPROCS для автоматической настройки параллелизма ввода-вывода / ЦП как оставшуюся часть # 2340.

Я заметил, что ни #2340, ни другой prune PR в настоящее время не распараллеливают загрузку переписанного индекса.