Terima kasih telah melaporkan masalah ini, saya rasa ini adalah bug.

Mungkin akan terjadi setiap kali direktori tingkat atas memiliki nama yang sama. Karena jalur lengkap tidak dipulihkan, hanya direktori tingkat atas.

Solusinya adalah merekonstruksi jalur lengkap setelah pemulihan, dan memulihkan setiap pohon ke jalur lengkap. Jadi jalur yang dihasilkan akan seperti /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . Saya pikir itu bisa diterima.

Apakah tambalan perlu diterapkan sebagai bagian dari pemulihan?
Atau, mungkin itu harus dilakukan selama pencadangan dengan membangun pohon tingkat atas berbeda yang menyertakan komponen jalur lengkap?

Saya juga curiga ini masalahnya. Saat ini, restic bekerja seperti ini:

Ketika dipanggil sebagai restic backup A/foo B/foo itu membuat struktur pohon dalam repositori yang terlihat seperti ini:

├── foo
└── foo

Jadi hanya komponen path terakhir dari argumen ke perintah backup yang diambil, hal ini menyebabkan masalah saat memulihkan snapshot tersebut.

Untuk memperbaiki ini, saya mengusulkan untuk menerapkan perilaku yang sama seperti tar , yang dalam hal ini akan membuat pohon berikut:

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

Ini akan membutuhkan beberapa pekerjaan di bagian pengarsipan restic. Saya tidak berpikir kita perlu menyentuh pemulihan sama sekali.

588 Saya melaporkan hal yang sama. Tapi yang satu itu memiliki kasus uji yang bisa Anda gunakan.

@ fd0 Saya mengusulkan untuk juga menyertakan opsi (--store-full-path) untuk mencadangkan yang secara eksplisit menyimpan jalur 'nyata' lengkap dari target pencadangan.

Alasannya adalah bahwa dalam kasus tar dan dengan beberapa alat cadangan lainnya Anda bisa mendapatkan pohon pemulihan yang sedikit berbelit-belit. Meskipun ini adalah default yang bagus, saya pribadi ingin jika pemulihan saya menyerupai seluruh tata letak sistem file asli untuk cadangan host. (Bahkan lebih baik jika pemulihan juga dapat mengawali nama host ke lokasi pemulihan)

@trbs Saya pikir default harus menyimpan path lengkap, dengan saklar untuk kasus khusus menggunakan path relatif. Alasannya adalah bahwa jalur rel dapat menghasilkan perilaku yang tidak terduga atau tidak ditentukan, tetapi abs tidak bisa. Jika Anda ingin meminta prefiks atau bentuk path mangling lainnya, saya sarankan itu adalah masalah yang sepenuhnya terpisah.

Saya telah memikirkan hal ini dan saya pikir kita perlu mengubah perilaku pencadangan agar selalu jalur lengkap (seperti yang diberikan pada baris perintah) disimpan. Itulah yang dilakukan tar , dan bekerja dengan sangat baik. Sayangnya ini merupakan peninggalan dari keputusan desain yang buruk di awal pengembangan restic.

+1 untuk --store-full-path

Benci hanya memberi +1, tetapi saya juga sangat tertarik dengan solusi untuk bug ini. Memiliki beberapa instalasi restic yang tertunda, di mana bug ini sayangnya merupakan showstopper.

Terima kasih @ fd0 untuk pekerjaan Anda dalam hal ini, saya mengerti tidak mudah untuk melepas lelah sekarang.

-1 untuk --store-full-path . Saya lebih suka melihat jalur lengkap selalu ada di cadangan dan kemudian memiliki --strip-components <N> untuk diambil bagiannya jika Anda tidak membutuhkannya pada waktu pemulihan. Artinya, data lengkap selalu tersedia di cadangan dan jika pengguna menghapus terlalu banyak komponen dari jalur pada waktu pemulihan dan karena itu menggabungkan subdirektori, ini menjadi kesalahan pengguna yang dapat dipulihkan.

Untuk mengawali nama host ke lokasi cadangan, ini tampaknya dapat dengan mudah dilakukan dari cmdline, karena kebanyakan orang tahu dari host mana mereka akan memulihkan sebelumnya :)

Mengingat bahwa Anda belum 1.0, saya memilih bahwa, jika perubahan besar harus dilakukan untuk mendapatkan perbaikan yang ideal, lanjutkan dan lakukan lebih cepat daripada nanti.

@mholt Saya setuju, saya sudah mengerjakan ini. Seperti yang saya katakan, ini disebabkan oleh keputusan desain yang buruk sejak awal dan perlu diperbaiki.

Hei @ fd0 - baru saja melihat 0,7 dirilis. Apakah ini (dan # 910 dan # 909) pada peta untuk 0.7.1?

Mungkin bukan untuk 0.7.1, tapi untuk 0.8.0 atau lebih. Saya sudah mulai mengerjakannya. Mungkin sedikit latar belakang: Ini disebabkan oleh kode pengarsip, yang merupakan kode tertua yang ada di restic. Sayangnya (karena saya baru mulai belajar Kembali pada 2013/2014) kode pengarsipannya sangat rumit dan saya membuat banyak kesalahan pemula (terlalu banyak konkurensi, terlalu banyak saluran). Saya juga mengkhawatirkan hal-hal yang ternyata tidak menjadi masalah sama sekali, dan mengabaikan hal-hal yang menjadi masalah (misalnya penanganan indeks).

Jadi, saya sudah mulai menerapkan ulang kode pengarsipan sepenuhnya, menggunakan konkurensi hanya jika masuk akal (yaitu memproses potongan individu) dan tidak membaca 20 file dari disk secara paralel. Kode ini juga mencakup berjalannya direktori yang benar dan akan memasukkan jalur lengkap ke dalam repo.

Untungnya, ini benar-benar hanya pengarsipan yang perlu disentuh, sisa kode akan terus berfungsi dengan baik (berkat desain restic dan repo).

apakah perubahan ini akan mempengaruhi repositori yang ada dan jika ya, bagaimana?

"mempengaruhi" dalam istilah "backup baru akan memiliki struktur yang sedikit berbeda", ya, tapi itu saja. Tidak ada migrate atau apapun yang dibutuhkan.

Jadi, # 1209 telah digabungkan dan memperbaiki situasi dengan mendeteksi konflik nama dan menyelesaikannya (dengan mengganti nama), tetapi masalah ini masih belum terselesaikan sepenuhnya. Saya sedang mengerjakannya :)

@ fd0 Adakah gagasan ketika kita mengharapkan snapshot yang berisi path lengkap asli? Kami sedang mengerjakan mengotomatiskan backup dan mengembalikan menggunakan restic.

Saat mengotomatiskan pemulihan, sangat penting memiliki jalur sumber yang utuh.

Jika saya memiliki server dengan dua direktori 'data' yang dicadangkan (dan ini tidak teoretis, kami memiliki sejumlah server dengan direktori 'data' Confluence dan JIRA yang perlu dicadangkan) - proses pemulihan perlu mengetahui yang mana direktori data milik Confluence dan direktori data milik JIRA. Nama seperti 'data' dan 'data-1' jelas tidak cocok di sini.

Saya pikir solusi terbaik untuk saat ini adalah membuat cadangan direktori data dalam snapshot terpisah dan menandai mereka dengan 'JIRA' atau 'Confluence'?

Tidak ada garis waktu, maaf.

Saya pikir solusi terbaik untuk saat ini adalah membuat cadangan direktori data dalam snapshot terpisah dan menandai mereka dengan 'JIRA' atau 'Confluence'?

Ya, tetapi per # 1225 Anda tidak akan dapat dengan mudah menggabungkannya menjadi satu repo nanti.

Mengenai opsi --store-full-path : rsync memiliki opsi ini: -R , --relative .
Mungkin menggunakan nama opsi yang sama untuk restic?

Untuk pencadangan sistem lengkap, saya telah menjelaskan cara penyelesaiannya di sini: https://forum.restic.net/t/full-system-restore/126/8 Ini tidak bagus tetapi akan berfungsi hingga # 1494 selesai.

Bug ini sedikit mengkhawatirkan saya, tetapi saya tidak dapat mereproduksinya di 0.8.3 dengan langkah-langkah yang disediakan. Apakah ini masih masalah terbuka?

Ya, sayangnya ini masih menjadi masalah.

Hm, saya tidak dapat meniru masalah ini, jadi saya tidak yakin apa yang saya lakukan berbeda. Saya melampirkan skrip pengujian saya.

test_restic_549.zip

Anda dapat mereproduksinya seperti ini:

$ 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

Untuk dua subdirektori, restic menggunakan nama dasar dari subdir tersebut sebagai dir level teratas di repo, jadi untuk dir1/subdir dan dir2/subdir keduanya subdir , itulah yang menyebabkan tabrakan.

Daftar snapshot terbaru menunjukkannya:

$ 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

Dalam kasus pengujian Anda, nama dasar $TESTDIR/dir1 dan $TESTDIR/dir2 berbeda ( dir1 vs. dir2 ) sehingga bug tidak terjadi.

Dari catatan rilis versi 0.9:

Cadangan pertama dengan rilis restic ini kemungkinan besar akan mengakibatkan semua file dibaca ulang secara lokal, jadi akan memakan waktu lebih lama. Pencadangan berikutnya setelah itu akan cepat lagi.

Saya hanya ingin memberi Anda beberapa statistik:

cadangan pertama:

-------------------------------------------------------------
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
-------------------------------------------------------------

yang ke dua:

-------------------------------------------------------------
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
-------------------------------------------------------------

jadi lebih lama, berarti lebih lama :-)
Pertahankan kerja bagus! 👍

@ fd0 , kerja luar biasa! Terima kasih banyak! Alat cadangan Anda telah menjadi favorit saya untuk semua cadangan di luar situs saya (menggunakan b2) :-)