Restic: Добавить команду для копирования всех данных в другой репозиторий

Это предназначено для обработки одноразовой копии из одного репозитория (A) в новый (B)? Или это должно быть более общим, выполняя «синхронизацию» или обновление измененного содержимого между (A) и (B) с момента последней синхронизации?

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

Учитывая медленное интернет-соединение, я хотел бы иметь возможность как можно более эффективно выполнять резервное копирование на s3 и другое место.

@witeshadow Я не уверен, как это можно сделать эффективно, поскольку данные зашифрованы в репозитории A с помощью мастера A ', и необходимо сделать репо B с другим мастер-ключом B`. Нам нужно прочитать все данные, расшифровать с помощью A`, зашифровать с помощью B` и записать. Невозможно оптимизировать это для низкой пропускной способности. Будет больно...

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

@ fd0 Я просто хотел проголосовать за эту функцию. Что я могу сделать, чтобы это произошло?

Вы могли бы реализовать это ... Функциональность сама по себе не сложна, настроить два бэкэнда - сложная вещь. Мы не поддерживаем доступ к более чем одному бэкэнду (например, есть только один $B2_ACCOUNT_ID ) ... поэтому я думаю, что эта функция зависит от правильного файла конфигурации (см. # 16).

Допустим, у нас есть два репозитория, A и B, и вы хотите синхронизировать A-> B, чтобы после завершения процесса набор BLOB-объектов (и снимков) в B был надмножеством набора BLOB-объектов в A .

Итак, вы открываете оба репозитория и загружаете индексные файлы для каждого из них. Затем вы перебираете индекс A для каждого большого двоичного объекта, проверяя, содержится ли этот большой двоичный объект также в B. Если это правда, переходите к следующему. Если это ложь, скачайте, расшифруйте, зашифруйте и загрузите в B.

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

Как я уже сказал, техническая реализация довольно проста :)

Большой! Спасибо за советы. У меня этот зуд, поэтому я посмотрю, смогу ли я найти время, чтобы почесать его, но в краткосрочной перспективе мне придется отказаться от этой функции restic merge . Если кто-то доберется до меня раньше меня, это нормально - или я в конце концов вернусь к этому!

Думаю, я уже реализовал ... / чешу затылок и ищу ...
... https://github.com/middelink/restic/tree/fix-323
Мне нужно проверить, компилируется ли он, эта ветка на 228 коммитов позади ...

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

Эээ ... Есть новости для простых пользователей, не имеющих навыков разработки, чтобы скомпилировать и опробовать предложение @ middelink?

Это в основном комментарий «я тоже», но я хотел бы иметь возможность копировать только определенные снимки из одного репо в другое, а не семантику «копировать все» или «синхронизировать»; например, делать ежедневные резервные копии в локальное хранилище, затем раз в неделю копировать только самые последние ежедневные копии в корзину s3 и т. д.

Что ж, тогда вам повезло, моя копия cmd принимает один или несколько идентификаторов снимков. На самом деле copy-all - это не то, что он делает. Вам нужно сначала перечислить идентификаторы ваших снимков, а затем объединить их в командной строке «restic copy». Поскольку я рассматриваю это как вырожденный вариант использования, я хорошо с этим справляюсь.

Не углубляясь в это слишком глубоко, возможно, некоторые обсуждения с ncw / rclone могут быть полезны ...

Меня также интересует функция слияния / копирования, у меня есть репозиторий на USB-накопителе, который я хотел бы слить / скопировать в мой центральный репозиторий (те же пароли).
Есть новости по этому поводу?

Похоже, ветвь форка обновлена ​​до master , но пока для нее нет PR.

@middelink Ваш код

@ theory2019 Сам код готов, но каждый раз, когда я сажусь, чтобы создать официальный пиар, я все время нахожу то, что мне нужно сделать, прежде чем он будет готов. Как документация, как невыпущенный / журнал изменений ...
Ах да, еще тесты! Я упоминал тесты? Нужны тесты: P

@middelink Fyi , я протестировал вашу ветку, перебросив ее в исходное состояние, и она работает довольно хорошо. Он создал новый снимок с тем же хостом, тегами и датой: +1:
Жду пиара: тада:

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

@middelink Не разрешите редактирование от сопровождающих - таким образом мы можем помочь вам с журналом изменений, документацией и т. Д.

Важно то, что у нас есть базовый PR, над которым можно работать. Я бы хотел, чтобы ваша работа продвигалась вперед, как и другие, я думаю :) Дайте мне знать, если вам понадобится помощь в создании PR!

@rawtaz Конечно. Позвольте мне синхронизировать и все такое. Почему-то раньше я не находил на это времени, но, похоже, у меня есть время.

Спасибо всем за вашу работу над этим!

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

@lfrancke При использовании команды copy вы специально перечисляете снимки, которые хотите скопировать. Другие, как существующие, так и несуществующие, и ранее существовавшие, но теперь удаленные и уже не существующие моментальные снимки, неприменимы.

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

Отлично, большое спасибо @rawtaz за быстрый и полезный ответ.