Restic: Data dari snapshot yang tidak lengkap.

Ah, hm. Apakah Anda memerlukan file tertentu, atau hanya "semua data yang ada"? Datanya ada di sana, dan restic memiliki semua cara untuk menariknya, tetapi itu berarti membuat skrip di sekitar restic (yang akan sangat lambat) atau menambahkan kode kustom untuk restic.

Pertanyaan jujur: seberapa penting data bagi Anda? Saya bisa meluangkan waktu hari ini untuk meretas sesuatu bersama-sama untuk Anda, yang akan memberi Anda akses ke hampir semua data yang telah diunggah ke repo, tapi mungkin tidak "siap produksi" seperti kebanyakan kode. :)

Data tersebut sangat penting bagi saya dan sayangnya tidak ada salinan lainnya. Saya tahu itu tidak ideal, tetapi itu adalah masalah yang saya coba selesaikan. Saya sedang mengupayakan perbaikan perangkat keras untuk mencoba mengembalikan volume secara online, tetapi itu tidak terlihat terlalu penuh harapan saat ini. Jika ada cara bagi saya untuk menentukan direktori dan dapat mengakses serta mengunduh semua yang ada di dalam direktori itu, itu akan menjadi penyelamat yang serius. Ini adalah data yang banyak (sebagian besar adalah proyek video), jadi opsi yang lebih cepat lebih disukai. Meskipun demikian, saya tidak terlalu tahu berapa banyak pekerjaan yang diperlukan dan saya menghargai bahwa ini adalah perangkat lunak gratis, tetapi saya akan sangat berterima kasih jika ini dapat dilakukan.

ok, saya akan melihat apa yang bisa saya lakukan.

Terima kasih banyak.

Anda dapat mulai dengan menjalankan restic rebuild-index , jadi kami memiliki indeks baru yang mencakup semua paket di repo.

Memulai itu sekarang.

Wow, Anda sangat murah hati @ fd0.

Jika saya dapat membantu menguji apa pun yang terkait dengan ini, beri tahu saya.

Haruskah restic rebuild-index menanyakan sandi repo saya? Belum. Saya menduga bahwa ini mungkin memakan waktu cukup lama karena jumlah data dalam repo. Saya sangat puas membiarkannya berjalan sepanjang akhir pekan, atau minggu depan jika perlu. Saya hanya ingin memastikan bahwa ini tidak memerlukan kata sandi dari saya sebelum saya meninggalkannya tanpa pengawasan untuk jangka waktu yang lama.

Hm, harusnya minta password sedini mungkin. Itu perlu mendekripsi semua header dari semua file di repo. Apakah Anda mungkin mengekspor variabel lingkungan RESTIC_PASSWORD , sehingga tidak memerlukan kata sandi dari Anda?

Ini harus mencetak sesuatu seperti ini sejak awal:

repository ed6136ad opened successfully, password is correct

Setidaknya saat dijalankan secara interaktif (tidak ada pengalihan stdout ke file log).

Anda juga dapat melewati rebuild-index jika 15 menit terakhir dari data yang diunggah tidak terlalu penting, kami selalu dapat melakukannya nanti.

Saya tidak memiliki set variabel lingkungan RESTIC_PASSWORD , tetapi saya akan mengaturnya dan membiarkan perintah berjalan. Itu tidak mengembalikan apa pun selama sekitar 10 menit, jadi saya memberikannya ctrl-c dan mencoba lagi. Sintaks saya benar, bukan? restic -r b2:MY_BUCKET_NAME:/ rebuild-index Bagaimanapun, data 15 menit terakhir seharusnya sangat kecil dibandingkan dengan total data yang diunggah, jadi saya akan sangat senang kembali lagi nanti.

ok, kalau begitu jangan jalankan rebuild-index dulu, jadi kita bisa mencoba kode pemulihan :)

Saya telah mendorong komit ke cabang recover-data , cukup buat restic ( go run build.go ) dan sebut seperti ini:

$ restic -r b2:MY_BUCKET_NAME:/ recover

Ini kemudian harus mencantumkan semua pohon di repo, menemukan pohon akar, dan membuat snapshot baru yang mereferensikan semua pohon akar:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

Kemudian Anda memiliki snapshot ( 26f25bf1 dalam hal ini) yang dapat Anda pulihkan, atau cukup gunakan restic mount untuk melihat-lihat di dalamnya. Anda juga dapat mencantumkannya:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

Direktori tingkat atas diberi nama setelah ID pohon, jadi mereka agak samar, tetapi tingkat berikutnya di bawah memiliki nama normal.

Beri tahu saya jika itu membantu Anda!

Jadi, untuk menambahkan sedikit cerita latar belakang: Saya membaca terbitan github, kemudian pergi mandi, dan berpikir, "hm, itu tidak terlalu sulit untuk dilakukan". Ternyata, saya benar, dan ternyata tidak. Jika fungsi ini bermanfaat untuk orang lain, kami dapat mengubahnya menjadi perintah yang tepat nanti, tetapi untuk saat ini saya harap ini berfungsi untuk Anda dan Anda dapat mengakses data yang sudah diunggah ke B2.

Berapa banyak data itu? Seberapa banyak Anda pulih?

Semoga berhasil!

Wow! Cepat sekali! Terima kasih banyak! Saya baru saja mengkloning repo dan akan mencoba membuatnya sekarang. Saya juga menemukan alasan mengapa indeks pembangunan kembali tidak berfungsi. Itu adalah masalah DNS di jaringan tempat server kami berada. Saya memperbaikinya dan mendapatkan Fatal: unable to create lock in backend: repository is already locked by PID 41208 jadi tampaknya unggahan saya tidak dihentikan dengan baik. Perintah unlock tampaknya telah membersihkannya dan membangun kembali indeks sedang berjalan.

Saya akan menyelesaikan sebanyak mungkin hal ini semampu saya hari ini, tetapi saya akan berangkat ke Michigan utara untuk akhir pekan dalam waktu sekitar 15 menit dan saya rasa akses internet saya tidak akan sangat baik di sana. Ini akan mendapatkan perhatian penuh saya pada hari Senin ketika saya kembali dan saya akan memberi Anda detail lebih lanjut :-)

Terima kasih banyak untuk ini! Maaf membuat Anda menggantung, tetapi saya akan menghubungi hari Senin.

Jika fungsi ini bermanfaat bagi orang lain, kami dapat mengubahnya menjadi perintah yang tepat nanti

Saya ingin membantu dengan cara apa pun yang saya bisa. Kecepatan unggah saya di sini adalah 1 Mbps sehingga pencadangan awal saya bisa memakan waktu hingga 3-6 bulan. Memiliki cara untuk memulihkan sebelum selesai akan menjadi fitur yang sangat baik, terutama jika tidak terlalu sulit, seperti yang Anda katakan. Beri tahu saya bagaimana saya bisa melayani! Terima kasih banyak telah mengerjakan ini! : D

Selain itu, solusi Anda cukup brilian, saya kira. Elegan dan cukup sederhana.

Maaf membuat Anda menggantung, tetapi saya akan menghubungi hari Senin.

Jangan khawatir tentang itu, saya hanya ingin tahu apakah itu berhasil: sunglasses:

Data aman di B2 dan tidak akan hilang. Bahkan perintah recover tidak akan mengubah data apa pun, ia hanya akan membacanya, menambahkan file lain dan snapshot, dan hanya itu.

Jadi, untuk memberi Anda sedikit latar belakang (mungkin saya akan mengembangkan ini menjadi posting blog nanti): Di bawah tenda, repositori restic berisi berbagai jenis file, misalnya snapshot dan data files:

• data file berisi sekumpulan lebih pendek tree atau data blob, dengan header di bagian akhir menjelaskan apa yang ada di dalam file dan di mana tepatnya
• snapshot file hanya berisi dokumen JSON kecil yang menjelaskan snapshot, yang mereferensikan tree

Ketika sebuah file disimpan dengan restic, itu dipotong menjadi data blobs, yang dikumpulkan dan disimpan bersama dalam satu atau lebih file di repositori. Nama file bersama dengan daftar referensi (ID) ke data blobs kemudian disimpan di pohon. Ketika restic selesai mengarsipkan direktori, daftar file (nama dan referensi untuk data blobs) disimpan sebagai tree blob ke dalam file data .

Untuk sub-direktori, restic menyimpan nama sub-direktori bersama-sama dengan referensi dari blob tree menjelaskan isinya di tree .

Di akhir proses restic backup kita memiliki root tree yang tidak direferensikan oleh pohon lain, tetapi berisi semua referensi ke semua pohon tingkat atas dan oleh karena itu (secara tidak langsung) ke semua file dan sub-dir di backup. Sebagai langkah terakhir, restic membuat file snapshot yang mereferensikan root tree .

Jika Anda memberi tahu restic untuk melupakan snapshot tertentu, pohon root tidak lagi dirujuk. restic prune mendeteksi ini dan menghapus pohon dan semua tree dan data gumpalan lainnya yang tidak diperlukan.

Secara umum, tree hanya disimpan di repositori jika semua file dan subdirektori di dalamnya telah berhasil disimpan. Jadi segera setelah gumpalan tree ada di sana, kita dapat mengasumsikan bahwa data yang direferensikannya (termasuk subdirektori) juga ada di sana.

Ketika restic dibatalkan selama pencadangan, akan ada sekumpulan tree blob di repo, bersama dengan data di file yang mereka referensikan. Jadi untuk memulihkan data, restic hanya perlu melakukan hal berikut:

• buat daftar semua ID pohon, catat pohon mana yang telah direferensikan (awalnya: tidak ada)
• untuk setiap pohon:
  
  
  
  • memuat pohon
  
  
  • untuk setiap entri di pohon:
    
    
    
    
    
    • jika adalah sebuah direktori, ia mereferensikan pohon lain, tandai pohon itu sebagai direferensikan dalam daftar
    
    
    
  
  

Selanjutnya, periksa daftar pohon lagi, buang semua referensi yang telah kita lihat. Pohon yang tersisa adalah pohon akar, yang berarti pohon yang (atau telah) direferensikan secara langsung oleh snapshot, atau yang "menggantung" sebagai hasil dari kegagalan restic backup .

Sebagai langkah terakhir, buat pohon baru yang mencantumkan semua pohon akar, simpan ke repo, lalu buat snapshot baru yang mereferensikan pohon baru ini.

Anda kemudian dapat menggunakan snapshot baru ini secara normal, kecuali untuk nama-nama samar dari direktori (yang merupakan ID pohon pendek dari pohon akar yang kami temukan).

Sebelum menggabungkan ini menjadi master, saya pikir kita harus melakukan hal berikut:

• Tambahkan opsi ke recover yang mengecualikan pohon akar yang direferensikan oleh snapshot yang ada, jadi kita hanya mendapatkan pohon akar yang benar-benar menjuntai. Mungkin perilaku ini seharusnya menjadi default, sebagian besar pengguna mungkin tidak begitu tertarik dengan data yang dapat mereka akses melalui snapshot yang ada…
• Juga buat data blob yang tidak direferensikan tersedia di snapshot baru, sehingga pengguna dapat mengumpulkan bagian-bagian file yang belum termasuk dalam objek tree .
• Setel metadata yang masuk akal untuk pohon baru dan snapshot baru. Saat ini itu sangat buruk (hanya cukup yang berhasil).
• Pelaporan kemajuan yang lebih baik, itu sangat hack sekarang

Pembaruan kecil untuk ini: Saya memulai rebuild-index sebelum saya pergi Kamis lalu. Itu mati sebelum saya kembali dengan read: connection reset by peer . Saya memulainya kembali kemarin dengan koneksi paralel nomor yang lebih tinggi ke b2 dan tampaknya berfungsi dengan baik. Sekarang hanya 5%, tapi saya perkirakan akan memakan waktu cukup lama. Bucket b2 memiliki sekitar 90TB di dalamnya dan direktori yang saya cadangkan mungkin memiliki sekitar 110-120TB di dalamnya.

Sejujurnya saya sangat terkesan bahwa restic tetap stabil selama proses upload. Saya mencoba cloudberry untuk Mac sebelum mencoba restic dan saya tidak dapat membuatnya berfungsi dengan data sebanyak itu. Saya menggunakan restic untuk mem-backup laptop saya di rumah dan saya menyukainya, jadi saya pikir saya akan mencobanya. Karena saya bahkan belum menyelesaikan unggahan awal saya, saya tidak tahu bagaimana sesuatu seperti prune akan berjalan, tetapi saya akan dengan senang hati memberi Anda informasi terbaru jika Anda membutuhkan data tentang bagaimana perilaku restic dengan volume data yang besar . Jika saya bisa membuatnya menyelesaikan semua operasi yang diperlukan untuk memelihara cadangan mingguan dalam waktu kurang dari seminggu, saya pikir itu akan menjadi kandidat yang bagus untuk menangani cadangan ini.

Untuk saat ini saya memiliki beberapa pertanyaan: Haruskah saya membiarkan rebuild-index berjalan sampai selesai sebelum saya mencoba recover ? Apakah saya akan kehilangan sesuatu jika tidak? Saya telah memikirkan hal ini dan saya pikir saya ingin memulihkan sebanyak mungkin pada percobaan pertama jika memungkinkan karena hal-hal memerlukan beberapa saat untuk menjalankan data sebanyak ini, tetapi jika lebih baik untuk membunuh ini, jalankan recover pertama dan rebuild-index kemudian, saya bisa melakukannya. Akankah menjalankan rebuild-index atau recover dengan flag --quiet mempercepat hal-hal seperti yang dilakukannya dengan perintah backup ?

OK keren! Saya akan merekomendasikan melakukan hal berikut:

• Batalkan rebuild-index
• Jalankan restic recover
• Lihat data apa yang dimuat snapshot yang baru dibuat

Jika Anda ingin mencoba, Anda dapat menjalankan rebuild-index lagi dan mengikis sisa megabyte data dari repo. Mungkin ukurannya kurang dari beberapa ratus megabyte, dan sepertinya ini tidak akan mengungkapkan data baru apa pun yang belum terdapat dalam snapshot. Tapi Anda bisa mencobanya :)

Saat rebuild-index berjalan, Anda tidak dapat mengakses repositori.

Akankah menjalankan rebuild-index atau memulihkan dengan --quiet flag mempercepat pekerjaan seperti yang dilakukannya dengan perintah backup?

Nggak.

Saya membiarkan semuanya berjalan semalaman dan tampaknya telah mengisi hard drive dan gagal:

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

Adakah cara mudah untuk mengetahui berapa banyak data yang harus diunduh oleh operasi ini atau cara untuk mengurangi berapa banyak yang diunduh?

Juga, jika saya ingin mengosongkan ruang disk ini restic cache --cleanup cara melakukannya?

Tidak, itu hanya menghapus direktori cache yang tidak digunakan selama 30 hari. Hapus saja direktori cache, yang seharusnya ada di suatu tempat di direktori home Anda.

Perintah mana yang sebenarnya Anda jalankan? Baik rebuild-index dan recover seharusnya tidak menyimpan banyak data di hard disk, kecuali untuk cache metadata ...

Tidak di mejaku saat ini. tapi itu seperti: ./restic -o b2.connections=x -r b2:mybucket:/ recover Saya pikir saya telah mengatur x untuk sesuatu yang besar. Itu mungkin bagian dari masalah. Saya dapat memulai ulang tanpa -o b2.connections=x bit. Saya menemukan direktori cache dan menghapusnya.

Pertama-tama, alat yang luar biasa.
Saya juga perlu mencadangkan terabyte data melalui koneksi yang lambat dan memiliki kemungkinan pencadangan gagal saat masih belum selesai. Apakah ada cara yang disarankan untuk mencadangkan hanya beberapa file dalam satu waktu?

Apakah ada cara yang disarankan untuk mencadangkan hanya beberapa file dalam satu waktu?

Apa yang biasanya berhasil (pernah saya dengar) adalah menyimpan bagian individu dari data sumber (misalnya direktori tunggal) dan jika sudah selesai, simpan semua direktori bersama-sama. Ketika data sumber tidak berubah, restic seharusnya mengunggah hampir tidak ada karena deduplikasi bawaan.

Tempat yang lebih baik untuk pertanyaan semacam itu adalah forum di https://forum.restic.net , pertanyaan (dan jawaban!) Jauh lebih dapat ditemukan di sana.

@pauletg jadi, bagaimana hasilnya?

Saya telah mengusulkan perintah baru recover di # 2056.

Saya belum banyak membuat kemajuan dalam pemulihan restic sejak posting terakhir saya. Kabar baiknya adalah kami telah berhasil menghidupkan kembali server dan data tidak rusak dalam kerusakan, jadi saya memiliki data saya. Perintah pemulihan tampaknya memenuhi HD mesin saya, sebelum dapat diselesaikan. Hal ini dapat disebabkan oleh beberapa faktor: Cadangan saya sangat besar dan saya menggunakan banyak koneksi ke b2 untuk mengunggah dan HD pada mesin yang saya gunakan untuk pemulihan relatif kecil. Saya yakin ini mungkin akan bekerja dengan baik jika cadangan saya berukuran lebih masuk akal. Beri tahu saya jika ada informasi lain yang akan berguna bagi Anda. Saya sangat menghargai Anda bekerja pada ini dan memiliki fitur ini tersedia untuk backup laptop saya sangat bagus.

Terima kasih untuk umpan baliknya! Jika Anda suka (dan memiliki banyak waktu), Anda dapat mencoba lagi dengan --no-cache , tetapi itu akan memakan waktu lebih lama. Saya akan menutup masalah ini saat # 2056 digabungkan.

Beri tahu kami jika Anda memiliki masukan tambahan! :)