Restic: Buat istirahat bekerja tanpa izin untuk menghapus file di GCS

Hei, terima kasih telah mengangkat masalah ini. Opsi --no-lock hanya untuk operasi yang didukung, seperti check . Operasi apa pun yang dapat menambahkan data (seperti backup ) tidak mendukungnya, bukan itu cara repo dirancang.

Apakah ini mungkin opsi untuk memberikan penghapusan akun layanan pada subdir locks/ ?

Atau buat cadangan ke direktori lokal, lalu gunakan misalnya rclone untuk menyinkronkan file baru ke cloud?

Apakah ini mungkin opsi untuk memberikan penghapusan akun layanan pada kunci/subdir?

Itu tidak mungkin di GCS.

@ fd0 restic backup dengan --no-lock berfungsi di sini dan saya menghapus semuanya di bawah /locks setelah beberapa jam secara otomatis.

% myrestic check
password is correct
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

tidak, itu tidak mungkin karena batasan ukuran.

@gebi "berhasil" berarti restic tidak mengembalikan kesalahan ketika Anda menentukan --no-lock , tetapi untuk operasi backup itu masih akan membuat file kunci. Sakelar --no-lock diperiksa untuk setiap operasi satu per satu, dan hanya beberapa (seperti check ) yang menghormatinya.

Saya memahami kasus penggunaan Anda, tetapi saya harus mengatakan bahwa saya sangat enggan untuk menambahkan dukungan untuk --no-lock ke backup , karena potensi tinggi yang digunakan orang tanpa memahami untuk apa itu. Sebagai contoh, katakanlah pencadangan membutuhkan waktu lebih lama dari yang diantisipasi, dan sementara pencadangan (tanpa kunci) masih berjalan, operasi prune dimulai pada mesin yang berbeda. Itu tidak akan melihat kunci apa pun, dan karena proses lainnya belum selesai, itu tidak akan melihat snapshot yang dibuatnya. Jadi proses pemangkasan tidak akan mengetahui data mana yang dirujuk oleh snapshot baru, dan bahkan akan menghapus file yang baru diunggah, karena ini tidak dirujuk oleh snapshot yang ada. Kemudian proses pencadangan selesai, mengunggah indeks baru (mengacu pada file yang dihapus) dan snapshot baru yang tidak dapat dipulihkan lagi.

Bagaimana Anda memastikan bahwa tidak ada proses restic backup yang berjalan saat Anda menjalankan prune ?

@fd0 Akun layanan yang digunakan oleh restic sama sekali tidak diizinkan untuk menghapus file di bucket GCS. Jadi tabrakan antara kedua perintah itu tidak mungkin.

IMHO itu akan menjadi properti yang sangat penting dan tujuan yang berharga untuk mendukung GCS sebagai penyimpanan anti-rusak di restic karena penyusup lebih sering pergi dan menghapus semua yang dapat mereka temukan termasuk cadangan, dengan akun layanan dengan izin hapus/tulis ulang penuh cadangan secara efektif tidak berharga.

@ fd0 tetapi seperti yang Anda katakan, harus ada peringatan yang dicetak bahwa ada kemungkinan korupsi data jika beberapa akun istimewa mengeksekusi prune secara paralel (mungkin mungkin untuk ditekan dengan beberapa i-know-what-im-doing mengalihkan).

ah... dan restic prune tidak pernah dipanggil pada kumpulan data ini, mereka dipecah berdasarkan tahun dan hanya sepanjang tahun yang dihapus (karena menghapus snapshot individual dari repositori tidak perlu dan terlalu lambat).

@ fd0 Ada ide untuk saran saya?
Jika saya memahami kode dengan benar, itu tidak akan membuat file kunci apa pun dan dengan demikian secara otomatis keluar dari restic (saat ini perlu dimatikan dengan -9).

Mendukung cadangan bukti kerusakan di restic akan luar biasa karena cukup sedikit sistem cadangan yang mendukung mode seperti itu dan ini adalah properti yang hampir selalu Anda inginkan.

Untuk plum paralel, mengapa tidak menggunakan "komit" dua fase untuk plum?
restic prune hanya menulis objek yang akan dihapus ke file, pada proses berikutnya itu akan berjalan secara normal yang berarti pertama membuat daftar objek untuk memangkas dari seluruh repositori, dan setelah itu hanya menghapus file yang ditemukan dalam daftar ditulis di jalankan sebelumnya. Semua objek yang tidak ada dalam daftar ditulis ke dalam daftar baru. Ini akan menghilangkan kebutuhan akan penguncian apa pun dengan jaminan keamanan untuk tidak menghapus objek dari menjalankan cadangan yang lebih pendek dari interval pemangkasan (yang jika pemangkasan hanya berjalan setiap bulan adalah margin keamanan yang cukup baik).
Ide ini akan memiliki keuntungan tambahan karena tidak memerlukan format repositori baru juga.

Lihat #1141 untuk diskusi pemangkasan tanpa kunci.

@ifedorenko ya, saya sudah membaca diskusinya, tetapi seperti yang telah disebutkan di sana pendekatan duplicacy memerlukan pembaruan ke format repositori, pendekatan sederhana ini meskipun tidak terlalu mewah tidak dan juga tidak memiliki persyaratan ekstensif mengenai atom operasi di toko backend.

Saya hanya menyarankan untuk membahas pemangkasan bebas kunci di #1141, jadi kami memiliki semua ide di satu tempat.

Saya telah memutuskan untuk tidak menambahkan dukungan untuk --no-lock untuk cadangan, setidaknya tidak untuk saat ini. Jika Anda menginginkan perilaku ini (dan bagi saya Anda merasa tahu apa yang Anda lakukan), salah satu caranya adalah dengan menambalnya ke restic secara manual dan membuatnya sendiri. Ini tambalannya: https://Gist.github.com/fcaf7a0cbc35b4e0bebc901fbacd3860

@ fd0 sayangnya karena kami benar-benar membutuhkan fungsionalitas untuk pencadangan WORM (tulis sekali baca banyak), dan sebagian besar pengguna pencadangan juga melakukannya, mereka tidak menyadarinya, atau hanya setelah kompromi pertama mereka di mana sebagian besar cadangan kemudian dihapus juga.

Saya telah melakukan fork restic dan membuat rilis pertama restic-worm yang harus kami gunakan dan akan terus memperbarui restic hulu Anda karena masuk akal untuk usecase kami.
Saat ini mencadangkan sekitar 10PB data dan berjalan dengan baik sejauh ini, saya benar-benar berharap kami akan menemukan kemungkinan untuk bekerja sama dan menambahkan fungsi ini ke hulu bahkan jika itu berarti kami harus mengujinya dan mempertahankannya, garpu tidak membantu kedua belah pihak.

https://github.com/mgit-at/restic/tree/v0.8.3-worm
https://github.com/mgit-at/restic/tree/backup-nolock

@gebi Saya dapat memahami kasus penggunaan Anda dan apa yang Anda coba lakukan. Menurut pendapat saya, hanya menambahkan patch kecil untuk memungkinkan --no-lock selama pencadangan berpotensi (ab)digunakan oleh terlalu banyak pengguna dengan cara yang salah, yang dapat menyebabkan hilangnya data. Itulah alasan saya tidak suka hanya menambahkannya.

Secara umum, proses pemangkasan tidak optimal, dan bahkan menggunakan file kunci sangat disayangkan, terutama untuk kasus penggunaan Anda. Itu yang saya buat selama fase desain awal, dan ini yang paling sederhana untuk diterapkan. Kami akan mengubahnya dan pindah ke sesuatu yang lebih baik dalam jangka panjang, pasti.

Saya setuju bahwa garpu sangat disayangkan dan tidak akan membantu kami berdua, meskipun itu hanya --no-lock yang ditambahkan untuk mendukung kasus penggunaan Anda. Saya bisa hidup dengan tambalan yang memungkinkan ini hanya dengan flag build worn khusus yang menonaktifkan perintah prune sama sekali dan menjalankan backup dan check tanpa file kunci . Apakah itu mungkin berhasil untuk Anda?

Saya sangat tertarik dengan hasil Anda bekerja dengan 10PB dalam repo restic, itu luar biasa!

@ fd0 hmm... semakin saya memikirkannya, semakin saya sampai pada kesimpulan bahwa mungkin kita harus menolak untuk mengizinkan restic prune pada backend seperti itu yang menerima snapshot tanpa kunci.

Jadi mengapa tidak membiarkan restic snapshot --no-lock membuat file kunci jika belum ada tetapi tidak menghapusnya?
Ini akan melarang restic untuk menjalankan operasi pemangkasan apa pun pada data secara paralel, tetapi tidak akan membatasi snapshot di masa mendatang (sejauh yang saya lihat mereka hanya berfungsi, terlepas dari berapa banyak file kunci yang ada).

Jika pengguna ingin memangkas backend penyimpanan seperti itu, _he_ harus memastikan tidak ada yang menulisnya secara bersamaan, yang benar-benar baik untuk kasus penggunaan yang dimaksud.

Jika kita mendapatkan #1141 ke dalam bentuk yang dapat digunakan yang mungkin menghilangkan batasan itu di kemudian hari, tetapi untuk saat ini saya akan baik-baik saja untuk membatasinya, itu akan luar biasa untuk memiliki fungsionalitas untuk menulis dengan snapshot ke ember GCS WORN di hulu.

akankah jalan ini berhasil untuk Anda?
Itu akan menciptakan cara yang aman untuk melakukan pencadangan WORN, memiliki fungsionalitas yang disertakan di hulu, dan pemangkasan bersamaan adalah tanggung jawab pengguna jika dia ingin menggunakan/mengimplementasikannya.

Saya berasumsi maksud Anda restic backup --no-lock ? Ini akan bekerja untuk backup , tetapi Anda akan berakhir dengan banyak file kunci dari waktu ke waktu...

Untuk operasi lain (seperti snapshots ) mengubah perilaku tidak akan berhasil: Awalnya kami telah menambahkan sakelar --no-lock untuk mendukung pengaksesan repositori pada media hanya-baca (seperti DVD) .

@fd0 ya maksud saya restic backup --no-lock , ya banyak file kunci akan menjadi hasilnya tetapi mereka dapat dihapus dari mesin memangkas data atau pertama-tama periksa apakah setidaknya ada satu file kunci dan hanya buat yang baru jika tidak ada file kunci.

Dan untuk operasi seperti snapshots itu akan menjadi perilaku yang sama seperti sekarang atau mengabaikan kesalahan?

Hm. Mungkin kita benar-benar dapat melakukannya: Tidak keluar dengan kesalahan jika file kunci tidak dapat dihapus. Itu akan berhasil dalam banyak kasus, terutama yang Anda minati.

Ya itu akan luar biasa!

btw... perilaku saat ini adalah loop dengan output kesalahan di mana restic tidak dapat dimatikan secara normal tetapi hanya dengan kill -9 (untuk kasus ini)

Uh, itu tidak baik, terima kasih telah menunjukkannya lagi.

Saya pikir Anda harus dapat menambahkan izin menulis dan menghapus penuh hanya untuk folder kunci dengan menggunakan ACL:
https://cloud.google.com/storage/docs/access-control/lists

Saya tidak mengujinya sendiri dan bisa salah.

@lukastribus akan luar biasa jika itu berhasil, tetapi tidak.

Tidak ada kunci "folder"/ untuk meletakkan ACL di atasnya, ember penyimpanan cloud google tidak berfungsi seperti itu, maaf.
Seseorang harus meletakkan ACL pada setiap objek individu di dalam namespace lock/ tetapi itu akan mengalahkan tujuannya.

@fd0 berita apa pun tentang fitur "Hm. Mungkin kita benar-benar dapat melakukannya: Tidak keluar dengan kesalahan jika file kunci tidak dapat dihapus. Itu akan berhasil dalam banyak kasus, terutama pada yang Anda minati."

Akan sangat luar biasa jika Anda dapat menambahkan ini ke restic, akan membuat hidup kita jauh lebih mudah dan itu akan menjadi tambahan yang berharga.

Bagaimana jika itu adalah kode keluar tertentu? Mungkin berguna untuk mengetahui bahwa ada kunci basi di repo ...

@fd0 berita apa pun tentang fitur "Hm. Mungkin kita benar-benar dapat melakukannya: Tidak keluar dengan kesalahan jika file kunci tidak dapat dihapus. Itu akan berhasil dalam banyak kasus, terutama pada yang Anda minati."

Tidak, sayangnya tidak ada berita. Saya tidak punya banyak waktu saat ini, jadi seseorang harus benar-benar melakukan pekerjaan di sini dan membuat prototipe ;)

Satu masalah kecil yang tidak disebutkan di sini (sejauh yang saya bisa lihat) adalah ketika operasi yang berjalan lama seperti backup dijalankan, restic mengganti file kuncinya sendiri setiap beberapa menit dengan yang baru dengan yang baru nama. Jadi tidak ada file kunci "tunggal", tetapi banyak.

Bagaimana jika itu adalah kode keluar tertentu? Mungkin berguna untuk mengetahui bahwa ada kunci basi di repo ...

Poin bagus, hm.

Dasar dari diskusi ini adalah membuat flag --no-lock tersedia untuk cadangan, yang sudah ada sebagai kode (dari Anda). Itu juga yang saat ini kami gunakan untuk mencadangkan semuanya.

@ fd0 apa yang akan menjadi cara pilihan Anda? saya telah mengirimkan tambalan yang kami gunakan di atas restic (yang untungnya disediakan oleh Anda, saya baru saja mengubahnya menjadi master). #1917

Mungkin cara lain bisa menjadi opsi untuk menyimpan file kunci secara terpisah (misalnya dalam ember tempat Anda memiliki akses tulis)?

Saya ingin tahu apa yang dilakukan orang lain untuk mengatasi situasi keamanan ini? Jika mesin pencadangan dikompromikan, bagaimana Anda memastikan penyerang tidak hanya menghapus semua cadangan?

Saya juga mengalami masalah yang sama. Saya tidak perlu (dan karena persyaratan data tidak bisa) memangkas cadangan. Menjalankan backup --no-lock akan menjadi solusi sempurna bagi saya. Apakah ada solusi yang layak di luar sana?

@ parkerp1 Kami menggunakan metode yang disarankan di sini secara efektif, yaitu berbicara dengan tenang dengan dua salinan rclone yang digawangi oleh tinyproxy, dan memiliki satu ember baca/tulis untuk file kunci dan satu ember tulis-saja untuk data. Artikelnya tentang Wasabi, tetapi bagian belakangnya tidak relevan dan kami menggunakannya dengan GCS. Meskipun tidak terlalu bersih, Dockerizing solusi ini membantu menyembunyikan kerumitannya.

@parkerp1 kami masih menggunakan patch kecil di atas restic https://github.com/mgit-at/restic/tree/backup-nolock untuk mencadangkan beberapa ratus TB data. Bekerja seperti pesona.
Sayangnya itu ditolak di hulu ...

Terima kasih @gebi dan @sdudley. Keduanya terlihat seperti pilihan yang bagus

Saya setuju dengan @fd0 bahwa menambahkan flag --no-lock akan berbahaya. Jika seseorang mendapatkan kesalahan kunci, mereka mungkin mencoba menambahkan bendera itu untuk melewatinya dan akhirnya merusak data mereka.

Alih-alih, mungkin di init mungkin ada lokasi file kunci alternatif yang ditentukan (dengan fakta bahwa lokasi kunci alternatif sedang digunakan disimpan di repo asli). Kemudian setiap perintah yang dipanggil dan lupa untuk menentukan lokasi kunci alternatif bisa gagal (misalnya "kesalahan: repo menggunakan lokasi kunci alternatif dan tidak ada lokasi alternatif yang diberikan"). Perintah juga akan gagal jika lokasi kunci alternatif disediakan tetapi repo asli tidak diatur untuk menggunakan lokasi kunci alternatif.

Ini akan memungkinkan perilaku lanjutan dan juga menjaga perintah reguler cukup mudah bagi mereka yang tidak menggunakan perilaku lanjutan.

Saya juga mengalami masalah yang sama. Saya tidak perlu (dan karena persyaratan data tidak bisa) memangkas cadangan. Menjalankan backup --no-lock akan menjadi solusi sempurna bagi saya. Apakah ada solusi yang layak di luar sana?

Dua opsi di luar kepala saya:

• Gunakan rest-server dengan flag --append-only - ini memungkinkan pengguna Anda hanya mencadangkan ke repositori mereka, mereka tidak akan dapat menghapus data.

• Gunakan sistem file di server repositori yang memungkinkan Anda memotret bagian penyimpanan yang relevan. Saya akan merekomendasikan menggunakan ZFS karena itu akan menjadi snapshot yang sangat murah, dan mudah diakses jika perlu. Ini tidak akan sama dengan tidak mengizinkan penghapusan, tetapi Anda tetap dapat selalu memiliki salinan snapshot terbaru, jadi penghapusan apa pun tidak ada gunanya.

Pendekatan lain adalah dengan menggunakan pembuatan versi objek . Dengan mengaktifkannya, penghapusan mungkin diizinkan untuk akun layanan yang digunakan oleh restic karena mereka hanya benar-benar menambahkan penanda penghapusan ke riwayat versi. Hanya izin untuk tindakan DeleteObjectVersion yang harus ditolak untuk mencegah penyerang melakukan kerusakan permanen.
Terus terang, saya tidak yakin tentang GCS, tapi saat ini saya menerapkan ini di S3/Wasabi dan terlihat menjanjikan.

@fd0 Apakah variabel lingkungan ala RESTIC_DANGEROUSLY_DO_NOT_LOCK_BACKUP menjadi pilihan? :)

@fd0 Apakah variabel lingkungan ala RESTIC_DANGEROUSLY_DO_NOT_LOCK_BACKUP menjadi opsi? :)

Tidak, saya rasa tidak. Saya telah menguraikan di https://github.com/restic/restic/issues/1544#issuecomment -386549926:

Saya bisa hidup dengan tambalan yang memungkinkan ini hanya dengan flag build usang khusus yang menonaktifkan perintah prune sama sekali dan menjalankan pencadangan dan memeriksa file tanpa kunci.