Спасибо, что сообщили об этой проблеме, я думаю, что это ошибка.

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

Решение состоит в том, чтобы восстановить полный путь после восстановления и восстановить каждое дерево до полного пути. Таким образом, результирующий путь будет иметь вид /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . Я считаю это приемлемым.

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

Я тоже подозреваю, что это так. На данный момент рестик работает так:

При вызове как restic backup A/foo B/foo в репозитории создается древовидная структура, которая выглядит следующим образом:

├── foo
└── foo

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

Чтобы исправить это, я предлагаю реализовать то же поведение, что и tar , которое в этом случае создаст следующее дерево:

.
├── A
│   └── foo
└── B
    └── foo

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

588 Я сообщил то же самое. Но у этого есть тестовый пример, который вы можете использовать.

@ fd0 Я предлагаю также включить параметр (--store-full-path) для резервного копирования, где он явно сохраняет полный «реальный» путь к цели резервного копирования.

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

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

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

+1 за --store-full-path

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

Спасибо @ fd0 за вашу работу, я понимаю, что сейчас непросто расслабиться.

-1 для --store-full-path . Я бы предпочел, чтобы полный путь всегда шел в резервной копии, а затем имел --strip-components <N> для удаления частей, если они вам не нужны во время восстановления. Это означает, что в резервной копии всегда доступны полные данные, и если пользователь удаляет слишком много компонентов из пути во время восстановления и, следовательно, объединяет подкаталоги, это становится исправимой ошибкой пользователя.

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

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

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

Привет @ fd0 - только что увидел, что 0.7 вышла. Это (и # 910 и # 909) на карте для 0.7.1?

Может не для 0.7.1, а для 0.8.0 или около того. Но я уже начал над этим работать. Может быть, немного предыстории: это вызвано кодом архиватора, который является самым старым кодом, присутствующим в restic. К сожалению (поскольку я только начинал изучать Go в 2013/2014 годах) код архиватора очень сложный, и я сделал много ошибок новичка (слишком много параллелизма, слишком много каналов). Я также беспокоился о вещах, которые оказались не проблемой, и упускал из виду то, что стало проблемой (например, обработка индекса).

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

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

повлияет ли это изменение на существующие репозитории, и если да, то как?

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

Итак, # 1209 был объединен, и это улучшает ситуацию, обнаруживая конфликты имен и разрешая их (путем переименования), но эта проблема все еще полностью не решена. Я работаю над этим :)

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

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

Если у меня есть сервер с двумя каталогами данных, для которых выполняется резервное копирование (и это не теоретически, у нас есть несколько серверов с каталогами данных Confluence и JIRA, для которых необходимо выполнить резервное копирование) - процесс восстановления должен знать, какие каталог данных принадлежит Confluence, а каталог данных - JIRA. Такие названия, как «данные» и «данные-1», здесь явно не подходят.

Я думаю, что лучший обходной путь на данный момент - это резервное копирование каталогов данных в отдельных снимках и пометка их с помощью «JIRA» или «Confluence»?

Нет графика, извините.

Я думаю, что лучший обходной путь на данный момент - это резервное копирование каталогов данных в отдельных снимках и пометка их с помощью «JIRA» или «Confluence»?

Да, но по # 1225 вы не сможете потом легко объединить их в одно репо.

Что касается варианта --store-full-path : rsync имеет этот вариант: -R , --relative .
Может быть, использовать то же название опции для restic?

Для резервного копирования всей системы я описал обходной путь здесь: https://forum.restic.net/t/full-system-restore/126/8 Это некрасиво, но будет работать до тех пор, пока не будет выполнен # 1494.

Эта ошибка меня немного беспокоила, но я не могу воспроизвести ее в 0.8.3, следуя инструкциям. Это все еще нерешенный вопрос?

Да, к сожалению, это все еще проблема.

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

test_restic_549.zip

Вы можете воспроизвести это так:

$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo

$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar

$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved

Для двух подкаталогов restic использует базовое имя подкаталога в качестве каталога верхнего уровня в репо, поэтому для dir1/subdir и dir2/subdir это оба subdir , что вызывает столкновение.

Листинг последнего снимка показывает:

$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar

В вашем тестовом примере базовые имена $TESTDIR/dir1 и $TESTDIR/dir2 отличаются ( dir1 против dir2 ), поэтому ошибка не возникает.

Из примечаний к выпуску версии 0.9:

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

Я просто хочу привести статистику:

первая резервная копия:

-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved

Files:         556 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved

Files:       11570 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved

Files:        2309 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved

Files:         312 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved

Files:       743172 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      84.927 MiB

processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved

Files:         441 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End:   Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------

второй:

-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved

Files:           0 new,     0 changed,   556 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved

Files:           0 new,     0 changed, 11570 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved

Files:           0 new,     0 changed,  2309 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved

Files:           0 new,     0 changed,   312 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved

Files:         292 new,     0 changed, 743172 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Added:      32.790 MiB

processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved

Files:           0 new,     0 changed,   441 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End:   Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------

так что намного дольше, значит намного дольше :-)
Продолжайте в том же духе! 👍

@ fd0 , отличная работа! Спасибо! Ваш инструмент резервного копирования стал моим любимым для всех моих удаленных резервных копий (с использованием b2) :-)