Вот более раннее воплощение этого запроса, которое я нашел: # 555

+1

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

Итак, позвольте мне подвести итог: вы используете restic backup /mnt/backup-snapshot , поэтому файл /mnt/backup-snapshot/foo на снимке равен /mnt/backup-snapshot/foo , но вы хотите, чтобы он был /foo . Это правильно?

Вы можете добиться этого с помощью restic> 0.9.0, изменив текущий каталог, просто запустите cd /mnt/backup-snapshot а затем restic backup . .

Это работает для вас?

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

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

трюк cd, к сожалению, не оптимален, поскольку у меня есть много (125) абсолютных путей, собранных из StdExclusions.plist (стандартный список исключений резервного копирования macOS), и все файлы и папки, которые mdfind может найти с установленным атрибутом com_apple_backup_excludeItem.

Просто оставьте проблему, если вы поместите / mnt в файл игнорирования и начнете резервное копирование из / mnt / fs-snapshot, он исключит себя.

Плюс cd $ path && restic backup. по-прежнему дает $ path в обзоре снимка, в то время как пути в снимке основаны на /.

Я нашел обходной путь с proot.

Я также хотел найти способ удалить префикс пути. Мой вариант использования немного отличается - я создаю моментальный снимок zfs ( fs@$(date +%s) ) и хотел сделать резервную копию, не монтируя его ( /path/to/mount/.zfs/snapshots/${TS} ) - таким образом, надеюсь, у меня нет беспокоиться о том, что моментальный снимок не размонтируется, а затем останется навсегда в случае сбоя.

Вывод restic forget для этого заставляет меня думать, что снимки с разными путями не будут забыты согласно расписанию (ежедневно / еженедельно / и т. Д.).

Комментарий proot от @blurayne был хорошей отправной точкой, думаю, я пришел к такому же выводу:

$snap_path="/path/to/where/snapshot/is/accessible"
$orig_fs="/path/to/filesystem"
proot -b "${snap_path}":"${orig_fs}" restic backup "${orig_fs}"

Это прекрасно работает, и теперь все снимки имеют один и тот же путь, при этом не требуется cd или pushd . Кроме того, proot доступен в пользовательском пространстве, поэтому, если резервное копирование не выполняется с правами root, это все еще возможно.

Мой вариант использования: сброс данных базы данных во временный каталог, например / tmp / tmpzmn28r02 (полученный с помощью mktemp или python mkdtemp ()), а затем его резервное копирование.
Этот метод пометит все файлы между двумя снимками как разные. Поэтому мне нужен способ указать restic полностью игнорировать префикс временного каталога.
Другой возможный вариант использования: сегодня у меня все мои изображения в '/ mnt / something / pictures', но завтра тот же контент будет в '/ mnt / external / pictures-from-home' (другая схема разделения / что-то еще)

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

Пока исправление не будет сделано, я воспользуюсь предложением proot - спасибо @blurayne и @

Привет! У меня похожий случай. Например, у меня есть папки

/srv/my/long/server1/path/data (with many subfolders and dozen of files)
/path/to/dump.sql
/path/certbot.tar.gz

поэтому я хочу получить резервную копию, например

/data
/dump.sql
/certbot.tar.gz

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

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

Я копирую в предопределенную папку резервного копирования (/ backup) все, что мне нужно, и там запускаю Restic backup (через компакт-диск). Но это решение работает только для небольших объемов данных.

Было бы здорово иметь возможность восстановления с помощью подпапки --include сразу после шаблона (или с включением этой маски). бывший.:
restic restore --include data --target /my/new/path
и получить как результат
/my/new/path/data

Спасибо @ whi-tw за решение с proot -b /path/i/wanted:./path_in_repo restic backup . - у меня работает.

Мой вариант использования - перенос снимков из других решений для резервного копирования в restic (Time Machine и образы дисков в моем случае).

Я переношу их из того места, где я монтирую образ или подкаталог снимка, созданного TM, который может быть очень длинным, например, /Volumes/TimeMachine-Backups/Backups.backupdb/MacBook Pro/2019-05-22-185113/Macintosh SSD/ .

Решение cd работает при использовании restic mount и restic restore , но при запуске restic snapshots отображается абсолютный путь к исходному снимку.

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

Флаг для установки альтернативного префикса тоже был бы идеальным для меня.

Это прекрасно работает, и теперь все снимки имеют один и тот же путь, при этом не требуется cd или pushd . Кроме того, proot доступен в пользовательском пространстве, поэтому, если резервное копирование не выполняется с правами root, это все еще возможно.

Это было бы хорошим обходным путем, но proot недоступен в macOS и, похоже, не появится в ближайшее время (большая часть кода написана специально для Linux): работает ли PRoot в MacOSX?

Есть ли еще один способ обхода проблемы?

Мой вариант использования: сброс данных базы данных во временный каталог, например / tmp / tmpzmn28r02 (полученный с помощью mktemp или python mkdtemp ()), а затем его резервное копирование.
Этот метод пометит все файлы между двумя снимками как разные.

Обратите внимание, что файлы, вероятно, в любом случае _ разные; резервные копии баз данных обычно включают метку времени в первых нескольких строках.

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

Обновление: у меня proot работал только на одной машине, на другой произошел сбой.
Альтернатива ему (более новая) - пузырчатая пленка.
Над ним добавлена ​​оболочка (прикреплена), которая должна работать с теми же параметрами -b. Вроде пока работает. Обратите внимание, что в зависимости от ваших потребностей и расположения каталогов вам, возможно, придется немного изменить оболочку.
Я надеюсь, что это поможет вам, ребята, но я с нетерпением жду поддержки внутри самого Restic.

proot.sh.txt

Я пробовал proot . Кажется, это нарушает возможность запуска restic без полномочий root с дополнительными возможностями (https://restic.readthedocs.io/en/stable/080_examples.html#full-backup-without-root); по крайней мере, у меня есть ошибки scan: Open: open /.pulse: permission denied , которых я не получал при запуске restic без proot .

Та же проблема с bwrap .

Так что для меня удаление префикса пути в самом restic все еще кажется полезным.

Эта отсутствующая функция затрудняет резервное копирование виртуальных машин.
Мои снимки виртуальной машины попадают во временную папку, а затем создаются резервные копии с помощью restic.
Это приводит к следующему:

ID        Time                 Host         Tags        Paths
--------------------------------------------------------------------------------------
02c536db  2020-04-10 14:28:27  resolver-02              /tmp/tmp.vOFFxxly9O/config.xml
c5709aed  2020-04-10 14:28:29  resolver-02              /tmp/tmp.vOFFxxly9O/sdb.img
a88cc1e7  2020-04-10 14:36:22  resolver-02              /tmp/tmp.FoY1j5JPIZ/config.xml
7c44e6ee  2020-04-10 14:36:24  resolver-02              /tmp/tmp.FoY1j5JPIZ/sdb.img
65456111  2020-04-10 14:37:48  resolver-02              /tmp/tmp.vjtI9JE3Iz/config.xml
eaced756  2020-04-10 14:37:49  resolver-02              /tmp/tmp.vjtI9JE3Iz/sdb.img
8eccec2c  2020-04-10 16:04:30  resolver-02              /tmp/tmp.YtLYRd0rNI/config.xml
34c897e1  2020-04-10 16:04:31  resolver-02              /tmp/tmp.YtLYRd0rNI/sdb.img
99b67b97  2020-04-10 16:07:53  resolver-02              /tmp/tmp.aWaEDqAaTq/config.xml
cad2c9d8  2020-04-10 16:07:54  resolver-02              /tmp/tmp.aWaEDqAaTq/sdb.img
--------------------------------------------------------------------------------------

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

Это нарушает restic forget потому что он не распознает один и тот же файл и сохраняет моментальный снимок для каждого экземпляра.

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

Например, здесь можно использовать теги config.xml и sdb.img . Затем добавьте --group-by host,tags при запуске restic forget .

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

Что делает эту функцию такой сложной для реализации?

Говоря как разработчик (не о restic, а о других проектах с открытым исходным кодом): часто не сложность функции мешает ее реализации, а скорее банальные вещи, такие как нехватка времени, мотивации или просто «реальная жизнь» ...

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

Привет всем, я начал работать над реализацией этой функции "кастомного корня". Сама реализация казалась простой, хотя мне пришлось выучить голанг, который раньше знал только C # ... В любом случае, я пытаюсь оценить, какую поддержку эта проблема все еще имеет, поскольку это происходит с 2018 года, 2 года назад . Я скоро перейду на https://github.com/TheRealVincentVanGogh/restic/tree/2092-feature-custom-path-prefix , если кто-то захочет помочь мне с golang 😅. Надеюсь, что вскоре позже я размещу здесь пул-реквест.

@TheRealVincentVanGogh Я не собираюсь изучать Go, но я все еще стремлюсь к этой функции и у меня есть тонна резервных копий, которые я все еще хочу перенести на рестик, но для этой проблемы. Откройте PR, как только у вас будет что-то, что выглядит так, как будто оно работает, и опубликуйте ссылку здесь, я проведу серьезное тестирование

@TheRealVincentVanGogh Как ваша запланированная реализация соотносится с PR # 2010?

@TheRealVincentVanGogh Как ваша запланированная реализация соотносится с PR # 2010?

@MichaelEischer О, @cdhowie может связать PR # 2010 с этой проблемой, чтобы избежать путаницы в будущем? Спасибо!

@themightychris Вот ссылка на этот пиар . Похоже, что в 2018 году разработчик тоже ушел ... любопытно.

Редактировать:

Кажется, есть некоторая двусмысленность между удалением префикса пути из файла моментального снимка VS. удаление префикса пути из каждой файловой структуры + файла моментального снимка. Похоже, PR # 2010 касается только первого . Поскольку OP искал «удалить этот ведущий путь из путей всех файлов резервных копий» (AKA, исправление пути на уровне файловой структуры), я должен вернуться к тому, что я сказал о привязке PR # 2010 к этой проблеме . Извините за упоминание cdhowie!

Тем не менее! @MichaelEischer Я всегда

PS Я сейчас очень занят, так что работа на какое-то время может затянуться; конечно, я опубликую PR, когда думаю, что у меня есть что-то, чем стоит поделиться со всеми вами! Будьте в безопасности! 😄