Было бы здорово.

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

Это было бы отличной возможностью!

Есть ли отзывы разработчиков по этой идее? Было бы очень хорошо. Например, я только что обнаружил, что программа, которую я создаю из git checkouts, создает огромные двоичные файлы (почти 100 МБ), и они без надобности копируются в мои резервные копии Restic. Я не использую Restic очень долго, так как я все еще нахожусь на этапе тестирования, поэтому удалить старые снимки, о которых идет речь, не проблема. Но эта проблема может возникнуть довольно легко, и было бы хорошо иметь долгосрочные решения для нее, кроме забывания каждого снимка.

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

Спасибо.

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

Это, вероятно, на самом деле не меняет усилия по реализации, но с точки зрения UX это можно сделать с довольно низким профилем, расширив команду backup вместо добавления совершенно новой команды:

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

Таким образом, вместо того, чтобы предлагать команду, которая изменяет снимки, это позволит создать новую резервную копию на основе существующего идентификатора снимка. Удаление файла будет достигнуто с помощью правил исключения.
Вся документация по restic backup может быть "повторно использована" (то есть почти ничего не нужно добавлять для этой новой функции).

@dnnr См. https://github.com/restic/restic/issues/1550#issuecomment -358536554

Однако я не слежу за вами здесь. Удаление данных из старых снимков - определенно отдельная операция, и для нее должна быть отдельная команда. Что-то вроде:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

И --snapshots вероятно, должен принять ключевое слово all для работы со всеми снимками (или всеми снимками с указанным --tag ). И команда, вероятно, должна потребовать подтверждения, набрав yes .

Также было бы хорошо, если бы у него была опция --patterns , которая удаляла бы пути, соответствующие заданным шаблонам.

purge - это один из возможных вариантов имени команды. erase также может быть хорошим выбором, как и delete . Что бы ни было выбрано, должно быть ясно, что операция удаляет данные безвозвратно . Мы говорим о программном обеспечении для резервного копирования, и любые опасные операции должны быть четкими, явными и требовать подтверждения.

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

На мой взгляд, это позволит сохранить набор команд более ортогональным по сравнению с добавлением новой команды, которая перекрывается с функциональностью существующих команд. Прямо сейчас есть backup , forget и prune и все они делают совершенно разные вещи. Добавление purge как вы это описываете, меняет это. Мое предложение - нет.

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

Я согласен с @alphapapa, что для этого типа операции должна быть отдельная команда. Это может быть purge , это неплохое имя, но в будущем могут быть другие аналогичные операции, например, @alvarolm уже предлагал переименовывать файлы.

По этой причине я думаю, что, возможно, добавление команды rewrite является лучшей альтернативой в этом случае, и пусть эта команда имеет, например, параметры --purge и --rename , предполагая, что последнее имеет отношение к осуществлять. Таким образом, последние команды будут, например, restic -r foo rewrite --purge snap1,snap2 path1 path2 ... и restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

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

Я не думаю, что это разумно, чтобы очистка была частью команды резервного копирования. С одной стороны, вы можете возразить, что все в порядке - вы выполняете операцию с резервной копией. Но с этим объяснением действия «удалить», «разблокировать и забыть» также должны быть частью команды резервного копирования, поскольку они также предназначены для сохранения данных в вашей резервной копии. Я не думаю, что это имеет смысл, поэтому я думаю, что это действительно должна быть отдельная операция / команда, например rewrite или purge .

@dnnr

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

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

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

Я не понимаю о чем ты. Дело обстоит наоборот. Эта предлагаемая команда очистки / удаления / перезаписи вообще не перекрывается с backup - она удаляет данные из существующих снимков . Он ортогонален к существующим командам.

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

Опять же, понятия не имею, о чем вы здесь думаете. purge полностью отделен от резервного копирования, забывания и удаления:

• backup : Создает новый снимок заданных путей.
• forget : Удаляет существующие снимки.
• prune : собирает неиспользуемые капли из забытых снимков в мусор.
• purge / rewrite / something: Удаляет файлы из существующих снимков.

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

@rawtaz Да, rewrite - хорошее предложение, потому что оно буквально переписывает существующие снимки. Я бы предложил такой интерфейс, как:

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

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

резервное копирование: создает новый снимок заданных путей.

Ну, в некотором смысле, изменяя содержимое снимка создает новый снимок (потому что это не то же самое снимок , как и раньше). Подумайте о git commit --amend , который создает новую фиксацию на основе существующей фиксации. Аналогия на самом деле очень уместна, поскольку этот билет, кажется, быстро движется к переосмыслению Git.

Вы предлагаете, чтобы команда резервного копирования работала в двух режимах, в одном из которых выполняется резервное копирование данных, а в другом - удаляются данные.

Я этого не говорил. С чего бы это? Есть forget и prune , которые отлично подходят для удаления вещей.

Что ж, в некотором смысле изменение содержимого снимка создает новый снимок (потому что это уже не тот снимок, который был раньше). Подумайте, git commit --amend, который создает новую фиксацию на основе существующей фиксации. Аналогия на самом деле очень уместна, поскольку этот билет, кажется, быстро движется к переосмыслению Git.

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

Я этого не говорил. С чего бы это?

Вы сказали:

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

Может тебе стоит объяснить поподробнее.

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

Давайте будем конкретнее. forget удаляет снимки , а prune удаляет капли . Мы предлагаем команду для удаления файлов из снимков . Это должна быть отдельная команда.

Хочу добавить свое мнение:

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

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

Мне не нравится имя purge из-за его сходства с prune . А как насчет change ? Затем у нас есть restic backup , restic restore и restic change .

Для поддерживаемых операций команды я видел запросы на:

• Удалите файлы, например --delete
• Переименовать файлы, например, --rename

Первое - это именно то, о чем (изначально) эта проблема, но действительно ли существуют варианты использования для переименования файлов?

Я думаю, что change больше похоже на то, чтобы что-то вынуть и что-то вставить, а не на изменение содержимого чего-то.

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

Возможно, кто-то из коренных англичан или американцев знает, что более подходящее :) Думаю, это сводится к лингвистике.

Хм, тогда modify ?

modify определенно лучше, чем change . Итак, либо rewrite либо modify из того, что было предложено до сих пор. Любопытно, что думают другие :)

Если речь идет только об удалении файлов, имеет ли смысл улучшить команду forget для работы со снимками и файлами? Или это было бы слишком сложно?

Если эта новая функция касается удаления и переименования (или чего-то еще), я бы проголосовал за modify .

Спасибо за ваш вклад @dimejo 👍

Я думаю, что когда вы переименовываете и / или удаляете, вы не forget ting (по крайней мере, не в первом случае).

ИМХО «переписать» лучше всего передает смысл.

Команда forget тоже очень сложная, мы не будем ничего добавлять к ней, если сможем;)

Если это будет отдельная команда, я бы тоже назвал ее modify (я бы тоже хотел modify-snapshot , хотя он довольно длинный). Он также достаточно универсален, чтобы быть подходящим местом для всех видов операций изменения файлов (переименование, возможно, даже добавление). Однако я все еще думаю, что все, кроме удаления файлов, сильно пахнет расползанием функций.

Кстати, я чувствую, что restic выиграет от категорий команд, подобно тому, что есть в Git с его командами сантехники. Прямо сейчас restic -h перечисляет все команды в лексическом порядке, смешивая низкоуровневые команды (например, cat , list , которые никогда не понадобятся "нормальным" пользователям) с первичные высокоуровневые команды.

Вы также можете рассмотреть update .

+1 за rewrite , это красивое оруэлловское кольцо. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? 😄

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

Пока это может быть что-то вроде:

$ restic edit 40dc1520 remove dir/file

В будущем мы могли бы реализовать удаление одного файла из нескольких снимков (входной список с идентификатором снимка или диапазоном дат).

Другие команды в контексте редактирования могут быть

• rename для переименования файлов и папок
• move для исправления структур файлов / каталогов, которые могли измениться

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

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

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

@rawtaz
Мои мысли (почти) точно.

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

Что касается операций, выходящих за рамки этого (то есть переименования, добавления), я разделяю ваши сомнения. Это особенность подкрадывания и не входит в рамки инструмента резервного копирования, ИМХО.

Я согласен: удаление файлов из снимков важно, так как очень легко случайно сделать резервную копию файлов, которые не собирались делать. Это часто необходимо как по соображениям безопасности, так и по причинам использования диска. Наличие этой функции может означать разницу между возможностью сохранить старые резервные данные или необходимостью «выбросить ребенка вместе с водой для ванны».

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

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

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

Я не думаю, что здесь нужно больше обсуждений, спасибо за участие!

Предложение по названию команды: restic purge .

Я с нетерпением жду этой функции. Спасибо

@ fd0
Есть обновления по этой функции? Хотел бы использовать :)
Мы используем restic в правительственной среде, и для них требуется удаление одного файла из резервной копии. При необходимости мы могли бы профинансировать некоторые работы!

Я тоже этого жду! Я предлагаю использовать что-то вроде базовой структуры для restic find .

restic purge [flags] PATTERN

Где можно ограничить purge до host (-H) snapshots (-s) or paths (--path)

Тогда, возможно, restic prune впоследствии выполнит фактическое удаление

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

Спасибо !

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

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

Это вариант использования?

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite и modify могут быть макросами для вышеуказанного процесса.

Для меня этого действительно достаточно @nullcake

Неплохо, @nullcake.

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

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

Итак, палец вверх. :)

Хотя это интересная идея, я боюсь, что команда backup уже слишком сложна, а добавление другого «источника» для резервной копии еще больше усложнит ее. Кроме того, эта функция будет работать только с данными, уже находящимися в репо (если быть точным, только с метаданными). Отдельная команда (например, purge или около того) могла бы красиво инкапсулировать функциональность.

У CrashPlan было интересное поведение: когда файл исключается, он удаляется из всех существующих снимков. Это можно было бы рассмотреть.

Это было бы отличной возможностью. Это было добавлено?

Неа.

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

Еще одно предложение для имени команды: scrub (хотя меня тоже устраивает purge , флаг --rename покажется мне странным). Мои мысли:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

Где --replace=clean удаляет любой измененный снимок, prune очищает и после этого запускает prune . --diff показывает разницу для любых измененных снимков. --dry-run избегает внесения каких-либо изменений в репо.

Также действительны все флаги --exclude из restic backup . Я полагаю, что --host и --time также имеют смысл (каждое из них заменяет значения ранее существовавшего снимка); --tag Редактирование уже выполнено restic tag .

Есть ли у разработчиков рекомендации, как это можно реализовать? Мне кажется (при беглом взгляде), что большая часть кода может быть помещена в файл cmd_scrub.go ; возможно, потребуется всего лишь несколько дополнений API к внутренней библиотеке, поскольку, похоже, это в основном операции с индексами, но, возможно, это наивно. Какая-либо предполагаемая сложность (я предполагаю, что в любом случае основная задача будет заключаться в тестировании)?

так как это очень-очень старая проблема .. есть ли шанс получить эту функцию?

Для всех, кто следит за обновлениями и отправляет их из Google, нет необходимости ждать, пока эта проблема никогда не будет реализована, просто используйте дубликат в то же время, он имеет первоклассную поддержку для удаления файлов пост-фактов из снимков.

Для всех, кто следит за обновлениями и отправляет их из Google, нет необходимости ждать, пока эта проблема никогда не будет реализована, просто используйте дубликат в то же время, он имеет первоклассную поддержку для удаления файлов пост-фактов из снимков.

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

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

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

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

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

Тем не менее, если кто-то сделает прочный PR, который красиво и четко написан, хорошо протестирован и не содержит ошибок и подготовлен в координации с сопровождающими, он обязательно будет рассмотрен для включения. Это конкретная проблема, в которой @ fd0 уже дал свое благословение на направление, поэтому основное внимание может быть сосредоточено на создании надежной реализации (которая, как мы знаем, не повредит репозиторий), а не на том, «должны ли мы добавить эту функцию», что хорошо .

Такой PR должен быть основным и служить отправной точкой, на которую при необходимости можно будет опираться. Пример того, что я имею в виду, это для начала:

• Просто укажите одну новую команду (например, rewrite так как за нее чаще всего голосуют в этом выпуске).
• Возьмите список снимков в качестве основного аргумента (включая поддержку all ), например, all или 098db9d5 или 098db9d5 af92db33 .
• Возьмите список из одного или нескольких --exclude <pattern> чтобы перечислить пути, которые должны быть исключены / удалены из моментального снимка (другими словами, вот --exclude которые отсутствовали при резервном копировании), например --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

Смысл здесь в том, чтобы получить минимальный старт в качестве доказательства концепции и минимально жизнеспособного продукта. После тестирования мы можем настроить его по мере необходимости, например, добавив другие аргументы --exclude-* из команды backup . Если мы создадим команду rewrite подобную этой, у нее будет почти такой же интерфейс, что и у команды backup которую она предназначена для «исправления»:

~restic -r / some / repo перезаписать все --exclude = " .o" --exclude = .unwanted --exclude = .DS_Storerestic -r / some / repo rewrite 098db9d5 af92db33 --exclude = " .o" --exclude = .unwanted --exclude = .DS_Store~

В связи с этим, возможно, работа, проделанная @middelink в https://github.com/restic/restic/issues/323, может быть использована в качестве вдохновения или основы для реализации, поскольку она выполняет некоторую обработку существующих снимков. Я собираюсь посмотреть, сможем ли мы начать работу над этим слишком рано.

@rawtaz

Спасибо за содержательный отзыв!

Всем привет.

Я добавил черновик реализации rewrite рядом с комментарием @rawtaz

Здесь он работает с тестовым репо, передает restic check --read-data без ошибок, но не очень много тестировал. Поэтому я настоятельно рекомендую не использовать его с важными данными.

Я попытался приблизить синтаксис к команде backup . Итак, --exclude , --iexclude и --exclude-file поддерживаются (но не тестируются). В идеале я также хочу увидеть вариант --exclude-if-present (идеальный рабочий процесс для меня - это что-то вроде «ой, резервное копирование не требуется, добавьте CACHEDIR.TAG и restic rewrite »). Но это довольно сложно, потому что в этом случае нам понадобится rewrite на том же хосте, где было сделано резервное копирование, и доступ к файловой системе для сбора этих файлов (плюс тонны магии с относительными путями). Так что не сейчас ...

Также мне не нравится идея заменять снимки по умолчанию, поэтому в настоящее время поведение по умолчанию - просто создать новый снимок с тегом rewrite . Но замена также возможна с помощью --inplace arg.

Любая обратная связь будет принята с благодарностью.

Привет Дмитрий,

Спасибо за эту реализацию, отличная работа!

Пока что он отлично работает в Linux с небольшим тестовым репозиторием из 600 файлов + несколько тестовых снимков. Восстановление работает, и diff показывает правильно исключенные папки. Я буду проводить более интенсивные тесты на «клонированном» реальном репо с большим количеством ГБ данных с более чем сотнями снимков. Я также попробую репозитории из Windows.

Одно предложение: есть возможность указать тег для снимков, содержащих исключения на этапе перезаписи. (сохраняя тег « rewrite » на вновь созданных снимках.)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

Это поможет идентифицировать те снимки, которые все еще содержат "_thisfileshouldberemoved.txt_". С другой стороны, более прямой --inplace работает, как ожидалось.

Опять очень хорошая работа.

@NovacomExperts Да, моей первоначальной мотивацией было сделать редактирование истории максимально безопасным. Очень легко исключить что-то важное с помощью --exclude * и практически невозможно восстановить из этого (с резервным копированием это просто вопрос повторного запуска нового резервного копирования). Что-то вроде --dry-run но с возможностью получить фактический снимок и явно удалить исходный снимок после проверки, что все в порядке.

Я полностью согласен с тем, что в настоящее время это полностью не достигнуто. Легко «наблюдать» за новыми снимками, но слишком сложно удалить старый. К тому же мне не нравится жестко запрограммированное имя снимка rewrite . Может быть, лучше иметь по умолчанию --inplace и ---keep-source-tagged before-rewrite --tag-destination after-rewrite или что-то в этом роде. ( --add-tag немного неясно, старый это или новый снимок).

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

PS. Мое первичное рестик-репо сейчас составляет около 2 ТБ. Попробую позже, после создания снимка LVM.

@dionorgua Ваша первоначальная мотивация полностью верна. Я отдаю свой голос за то, чтобы все оставалось таким, с «опасной» опцией --inplace как можно дальше от пользователя (определенно не по умолчанию). Я бы предпочел ошибку отсутствия аргумента в --keep-source-tagged / --tag-destination чем --inplace по умолчанию.

Но согласен, будем ждать отзывов по этому поводу.

Вчера я забыл клонированное тестовое репо (65 ГБ) внутри папки, резервное копирование которой было выполнено рестиком в течение ночи. Я мог бы получить вчерашний снимок forget , но пошел ва-банк и попробовал вашу реализацию. После forget + prune я успешно удалил 65 ГБ из репо на 400 ГБ. Все хорошо, ошибок не обнаружено.

Я тестирую более интенсивно с данными, которые охватывают несколько снимков.

Ваше здоровье

Я заменил этот неправильный запрос на вытягивание # 2720 новым, потому что старый был создан из основной ветки. Только что добавлена ​​одна недостающая проверка ошибок. Извините за лишний шум

Хм, тогда modify ?

Очень поздно для этого, но _rectify_ - это мое предложение для команды delete-specific-file-from-backup.

2731 захватывающий, большое спасибо!

Очень поздно для этого, но я предлагаю исправить это для команды delete-specific-file-from-backup.

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