Restic: Разрешить смешивание шаблонов включения и исключения для резервного копирования и восстановления

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

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

Это другая проблема, когда список файлов / каталогов для резервного копирования берется из стандартного ввода, а не из аргументов командной строки. Как вы думаете, это ценно? Если да, не могли бы вы добавить проблему?

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

Возможно, вам стоит просто скопировать синтаксис rsync --exclude / - include / - exclude-from, у них 20-летний опыт работы :-)
(по крайней мере, добавьте несколько примеров текущего синтаксиса в руководство пользователя, поскольку неясно, являются ли «/ foo» и «foo» одинаковыми или поддерживается ли «* .c».

Ах, спасибо за комментарий, я добавил проблему с отсутствующими примерами в руководстве: https://github.com/restic/restic/issues/396

Честно говоря, мне совсем не нравится синтаксис фильтров из rsync, потому что правила слишком сложные. Но посмотрим, что у нас получится.

Любые обновления? Это определенно обязательный вариант. В настоящее время невозможно даже прочитать список файлов для резервного копирования со стандартного ввода:

$ find -name '*.go' | restic backup --files-from -
open -: no such file or directory

тогда как это можно было бы записать как

restic backup --exclude '*' --include '*.go'

Хм, чтение списка файлов из stdin может быть достигнуто путем вызова restic следующим образом:

$ find -name '*.go' | restic backup --files-from /dev/stdin

Если хотите, я бы принял PR, который добавляет обработку - за --files-from . :)

@opennota Не могли бы вы описать свой вариант использования? Нам было бы интересно.

Проблема с тире ( - ) отслеживается как # 769.

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

Если хотите, я бы согласился с PR, который добавляет обработку - для --files-from. :)

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

Вы можете эмулировать это поведение, используя sed и именованные каналы:

restic --exclude-file <(sed -n 's/^- \(.*\)/\1/p' files.list) --files-from <(sed -n 's/^+ \(.*\)/\1/p' files.list)

Строки, начинающиеся с - , исключаются, а строки с + включаются.

Я думаю, что хорошая модель - это то, что borg недавно реализовал для --pattern и --patterns-from
https://borgbackup.readthedocs.io/en/stable/usage/help.html#borg -help-patterns
Не столько разные селекторы стилей, сколько опции для указания корневых путей, включения правил, правил исключения и правил исключения без рекурсии в файле.

Почему бы просто не использовать стандартный формат игнорирования, который использует .gitignore ? например.

# ignore everything
*
# include $HOME/.local
!$HOME/.local

--Include планируется реализовать?

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

Предоставление списка файлов с помощью --files-from не решает проблему полностью, поскольку подкоманда snapshots отобразит гигантский список файлов, а подкоманда forget не работает должным образом.

Мой вариант использования - резервное копирование моего дома, и у меня есть список путей с некоторыми исключениями и некоторыми исключениями для исключения. Базовый список путей содержит уже сотню пунктов. Поскольку все меньше $HOME , я ожидаю, что смогу сказать что-то вроде --exclude=** --include=~/path1 --include=~/path2 --exclude=~/path2/something --exclude=*~ . Итак, чтобы определить, следует ли включать путь, он должен быть сопоставлен с каждым --exclude и --include в правильном порядке, и последнее совпадение побеждает.

Я думаю, что PR @vincentbernat - эффективное решение этого требования.

_Summary: разрешить отрицательные шаблоны в стиле gitignore указывать правила исключения как для резервного копирования, так и для восстановления.

Эффективно пользуюсь уже несколько недель.

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

b951f6a2  2019-06-15 11:30:18  elvandar    manual      /Users/daniel/Desktop
                                                       /Users/daniel/Documents
                                                       <lots more...>

к:

d0c0bed1  2019-06-18 08:20:57  elvandar                /Users/daniel

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