Itu akan sangat bagus.

Itu juga akan memungkinkan penghapusan data sensitif yang dimasukkan tanpa disadari.

Ini akan menjadi fitur yang bagus!

Adakah umpan balik dari para pengembang tentang ide ini? Ini akan sangat bagus. Sebagai contoh, saya baru saja menemukan bahwa program yang saya buat dari git checkout telah membuat binari yang sangat besar (hampir 100 MB), dan ini telah dicadangkan di cadangan Restic saya secara tidak perlu. Saya sudah lama tidak menggunakan Restic, karena saya masih dalam tahap pengujian, jadi tidak masalah untuk menghapus snapshot lama yang dimaksud. Tetapi masalah ini dapat terjadi dengan mudah, dan akan lebih baik jika memiliki solusi jangka panjang untuk itu, selain melupakan setiap snapshot.

Saya kira mungkin untuk menulis skrip untuk memulihkan setiap snapshot, menghapus file yang tidak diinginkan, dan mencadangkan kembali snapshot dengan mengatur tanggal secara manual, tetapi jelas itu akan memakan waktu yang sangat lama. Akan sangat bagus jika Restic bisa melakukan ini secara native.

Terima kasih.

Saya pikir ada beberapa kasus penggunaan yang valid untuk ini. Sepertinya fitur yang sangat bagus untuk dimiliki. Saya mungkin akan menggunakannya sendiri di beberapa titik.

Ini mungkin tidak benar-benar mengubah upaya implementasi, tetapi dari sudut pandang UX, ini mungkin dilakukan dengan profil yang agak rendah dengan memperluas perintah backup alih-alih menambahkan perintah yang sama sekali baru:

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

Jadi, alih-alih menawarkan perintah yang mengubah snapshot, ini akan memungkinkan membuat cadangan baru berdasarkan ID snapshot yang ada. Menghapus file akan dicapai dengan aturan pengecualian.
Semua dokumentasi pada restic backup pada dasarnya dapat "digunakan kembali" (yaitu, hampir tidak ada yang perlu ditambahkan untuk fitur baru ini).

@dnnr Lihat https://github.com/restic/restic/issues/1550#issuecomment -358536554

Namun, saya tidak mengikuti Anda di sini. Menghapus data dari snapshot lama jelas merupakan operasi yang berbeda dan harus memiliki perintahnya sendiri. Sesuatu seperti:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

Dan --snapshots mungkin harus menerima kata kunci all untuk beroperasi pada semua snapshot (atau semua snapshot dengan --tag ditentukan). Dan perintah tersebut mungkin memerlukan konfirmasi dengan mengetikkan yes .

Akan lebih baik jika memiliki opsi --patterns , yang akan menghapus jalur yang cocok dengan pola yang diberikan.

purge adalah salah satu kemungkinan untuk nama perintah. erase mungkin juga merupakan pilihan yang baik, serta delete . Apa pun yang dipilih, itu harus memperjelas bahwa operasi itu menghapus data secara permanen . Ini adalah perangkat lunak cadangan yang sedang kita bicarakan, dan setiap operasi berbahaya harus jelas, eksplisit, dan memerlukan konfirmasi.

Yah, saya meninggalkan langkah di mana Anda akan menghapus snapshot sumber sesudahnya (menggunakan forget , lalu mungkin prune ), karena saya pikir itu sudah jelas.

Menurut pendapat saya, melakukannya seperti ini akan membuat perintah diatur lebih ortogonal dibandingkan dengan menambahkan perintah baru yang tumpang tindih dengan fungsionalitas perintah yang ada. Saat ini, ada backup , forget dan prune dan mereka semua melakukan hal-hal yang benar-benar terpisah. Menambahkan purge seperti yang Anda gambarkan, mengubahnya. Saran saya tidak.

karena kami mengusulkan satu operasi file, alangkah baiknya jika dapat mengganti nama.

Saya setuju dengan @alphapapa bahwa harus ada perintah yang berbeda untuk jenis operasi ini. Mungkin purge , itu bukan nama yang buruk, sekali lagi mungkin ada operasi serupa lainnya di masa mendatang, misalnya @alvarolm sudah menyarankan untuk dapat mengganti nama file.

Untuk alasan itu saya pikir mungkin menambahkan perintah rewrite adalah alternatif terbaik dalam kasus ini, dan membuat perintah itu memiliki misalnya opsi --purge dan --rename , dengan asumsi yang terakhir relevan dengan melaksanakan. Jadi perintah terakhirnya adalah misalnya restic -r foo rewrite --purge snap1,snap2 path1 path2 ... dan restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

Yang mengatakan saya tidak sepenuhnya yakin mengganti nama adalah sesuatu yang masuk akal untuk diterapkan - ini cukup jauh dari apa yang dimaksud dengan program cadangan. Tapi pasti, kenapa tidak.

Saya tidak berpikir itu bijaksana untuk memiliki hal-hal pembersihan menjadi bagian dari perintah cadangan. Dalam satu perspektif, Anda dapat berargumen bahwa itu baik-baik saja - Anda melakukan operasi pada cadangan Anda. Tetapi dengan alasan itu, tindakan pangkas dan buka kunci dan lupakan juga harus menjadi bagian dari perintah pencadangan, karena mereka juga tentang memelihara barang-barang di cadangan Anda. Saya tidak berpikir itu masuk akal, jadi saya pikir itu memang harus menjadi operasi/perintah yang terpisah, misalnya rewrite atau purge .

@dnnr

Yah, saya meninggalkan langkah di mana Anda akan menghapus snapshot sumber sesudahnya (menggunakan lupakan, lalu mungkin pangkas) , karena saya pikir itu sudah jelas.

Ini jelas tidak jelas. Juga lebih baik jika Restic menanganinya untuk pengguna, daripada pengguna harus melacak ID snapshot mana yang telah berubah dan perlu dilupakan -- yang akan cukup membebani jika pengguna menulis ulang semua snapshot dalam repo.

Menurut pendapat saya, melakukannya seperti ini akan membuat perintah diatur lebih ortogonal dibandingkan dengan menambahkan perintah baru yang tumpang tindih dengan fungsionalitas perintah yang ada.

Saya tidak mengerti apa yang Anda maksud. Sebaliknya adalah kasusnya. Perintah purge/delete/rewrite yang diusulkan ini tidak tumpang tindih dengan backup sama sekali--ini menghapus data dari snapshot yang ada . Hal ini ortogonal untuk perintah yang ada.

Saat ini, ada cadangan, lupakan, dan pangkas dan semuanya melakukan hal-hal yang benar-benar terpisah. Menambahkan pembersihan seperti yang Anda gambarkan, mengubahnya. Saran saya tidak.

Sekali lagi, tidak tahu apa yang Anda pikirkan di sini. purge benar-benar terpisah dari pencadangan, pelupaan, dan pemangkasan:

• backup : Membuat snapshot baru dari jalur yang diberikan.
• forget : Menghapus snapshot yang ada.
• prune : Sampah-mengumpulkan gumpalan yang tidak digunakan dari snapshot yang terlupakan.
• purge / rewrite /whatever: Menghapus file dari snapshot yang ada.

Anda mengusulkan untuk membuat perintah backup beroperasi dalam dua mode, salah satunya mencadangkan data, dan yang lainnya akan menghapus data.

@rawtaz Ya, rewrite adalah saran yang bagus, karena secara harfiah menulis ulang snapshot yang ada. Saya akan menyarankan UI seperti:

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

Saya sarankan untuk tidak menggunakan koma sebagai pemisah, karena membuat pembuatan baris perintah dalam skrip jauh lebih rumit.

backup: Membuat snapshot baru dari jalur yang diberikan.

Yah, dalam arti tertentu, memodifikasi konten snapshot adalah membuat snapshot baru (karena itu bukan snapshot yang sama seperti sebelumnya). Pikirkan git commit --amend , yang membuat komit baru berdasarkan komit yang ada. Analogi ini sebenarnya cukup pas, karena tiket ini tampaknya bergerak cepat menuju penciptaan kembali Git.

Anda mengusulkan membuat perintah pencadangan beroperasi dalam dua mode, salah satunya mencadangkan data, dan yang lainnya akan menghapus data.

Saya tidak mengatakan itu. Mengapa? Ada forget dan prune , yang baik-baik saja untuk menghapus sesuatu.

Nah, dalam arti tertentu, memodifikasi konten snapshot adalah membuat snapshot baru (karena itu bukan snapshot yang sama seperti sebelumnya). Pikirkan git commit --amend, yang membuat komit baru berdasarkan komit yang ada. Analogi ini sebenarnya cukup pas, karena tiket ini tampaknya bergerak cepat menuju penciptaan kembali Git.

Kamu benar. Tetapi pada saat yang sama, Restic bukan git, dan tidak dirancang untuk memerlukan pengetahuan tentang pengalamatan berbasis konten agar berfungsi. Terlepas dari cara kerjanya, saya pikir, bagi pengguna, perintah yang kami usulkan harus dipertimbangkan untuk mengubah snapshot yang ada, bukan membuat yang baru, oleh karena itu harus menjadi perintah yang berbeda.

Saya tidak mengatakan itu. Mengapa?

Nah, Anda berkata:

dari sudut pandang UX, ini mungkin dilakukan dengan profil yang agak rendah dengan memperluas perintah cadangan alih-alih menambahkan perintah yang sama sekali baru

Mungkin Anda harus menjelaskan lebih detail.

Ada lupa dan pangkas, yang baik-baik saja untuk menghilangkan sesuatu.

Mari kita lebih spesifik. forget menghapus snapshot , dan prune menghapus blob . Kami mengusulkan perintah untuk menghapus file dalam snapshot . Itu harus menjadi perintah yang berbeda.

Saya ingin menambahkan pendapat saya:

Saya pikir memiliki cara untuk memodifikasi snapshot dalam repo itu berharga, berdasarkan umpan balik berapa banyak orang yang ingin memiliki sesuatu seperti ini.

Perintah harus independen dari perintah backup , tidak hanya karena alasan ortogonalitas (yang cukup mirip Go), tetapi juga karena pertimbangan praktis: Perintah backup sudah cukup rumit jadi saya ingin memisahkan perintah lain darinya.

Saya tidak suka nama purge , karena kemiripannya dengan prune . Bagaimana dengan change ? Kemudian kita memiliki restic backup , restic restore dan restic change .

Untuk operasi perintah yang didukung, saya telah melihat permintaan untuk:

• Hapus file, misalnya --delete
• Ganti nama file, misalnya --rename

Yang pertama persis tentang masalah ini (awalnya), tetapi apakah benar-benar ada kasus penggunaan untuk mengganti nama file?

Saya pikir change terdengar lebih seperti mengeluarkan sesuatu dan memasukkan sesuatu, daripada mengubah konten sesuatu.

Bayangkan repo/cadangan/snapshot adalah ember. Perubahan lebih seperti menukar ember itu sendiri dengan sesuatu yang lain, atau mengambil sesuatu darinya dan memasukkan sesuatu ke dalamnya, daripada mengambil sesuatu di dalam ember, memodifikasinya sedikit, dan meletakkannya kembali.

Mungkin beberapa orang Inggris/Amerika asli tahu mana yang lebih tepat :) Ini bermuara pada linguistik saya pikir.

Hm, modify lalu?

modify jelas lebih baik daripada change . Jadi rewrite atau modify dari apa yang telah diusulkan sejauh ini. Penasaran apa pendapat orang lain :)

Jika ini hanya tentang menghapus file, apakah masuk akal untuk meningkatkan perintah forget agar berfungsi dengan snapshot dan file? Atau akankah ini terlalu rumit?

Jika fitur baru ini tentang menghapus dan mengganti nama (atau yang lainnya), saya akan memilih modify .

Terima kasih masukannya @dimejo 👍

Saya pikir ketika Anda mengganti nama dan/atau menghapus, Anda tidak forget ting (setidaknya tidak dalam kasus sebelumnya).

IMHO "menulis ulang" menyampaikan arti yang terbaik.

Perintah forget juga sangat kompleks, kami tidak akan menambahkan apa pun jika kami dapat membantu;)

Jika itu akan menjadi perintah terpisah, menyebutnya modify akan menjadi favorit saya juga (saya juga ingin modify-snapshot , meskipun agak panjang). Ini juga cukup umum untuk menjadi tempat yang tepat untuk semua jenis operasi modifikasi file (mengganti nama, bahkan mungkin menambahkan). Namun, saya masih berpikir bahwa apa pun selain menghapus file sangat berbau fitur creep.

Omong-omong, saya merasa restic akan mendapat manfaat dari kategori perintah, mirip dengan apa yang dimiliki Git dengan perintah pipa ledengnya. Saat ini, restic -h mendaftar semua perintah dalam urutan leksikal, mencampur perintah tingkat rendah (misalnya, cat , list , yang tidak akan pernah dibutuhkan oleh pengguna "normal") dengan perintah tingkat tinggi utama.

Anda mungkin juga mempertimbangkan update .

+1 untuk rewrite , ia memiliki cincin Orwellian yang bagus. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? 😄

Saya ingin mengusulkan perintah edit . Berdasarkan semua umpan balik tentang masalah ini, bagi saya tampaknya kami akan berakhir dengan beberapa tindakan untuk edit satu atau beberapa snapshot.

Untuk saat ini mungkin hanya sesuatu seperti:

$ restic edit 40dc1520 remove dir/file

Di masa mendatang, kami dapat menerapkan penghapusan satu file dari beberapa snapshot (masukkan daftar ID snapshot atau rentang tanggal).

Perintah lain di bawah konteks edit mungkin

• rename untuk mengganti nama file dan folder
• move untuk memperbaiki struktur file/dir yang mungkin telah berubah

Saya percaya penting bahwa kami mengizinkan tindakan ini untuk dieksekusi pada satu atau beberapa snapshot (berdasarkan ID atau mungkin sejumlah tanggal atau rentang).

Saya masih tidak yakin tentang berapa banyak restic yang dapat dilakukan dengan data yang dicadangkan. Maksud saya, ini dimaksudkan untuk mencadangkan data untuk mempertahankan seperti apa tampilannya pada titik waktu tertentu. Ini tidak dimaksudkan untuk menjadi NAS.

Saya terutama tidak melihat validitas dalam kasus penggunaan mengganti nama dan menghapus file. Maksud saya, mengapa Anda mengubah file di disk lokal Anda dan kemudian bermain-main dengan cadangan Anda untuk menjaga pohon file tetap sinkron dengan data Anda saat ini. Itu tidak masuk akal bagi saya. Bisakah Anda menguraikan kasus penggunaan itu?

@rawtaz
Pikiran saya (hampir) persis.

Saya berpendapat validitas menghapus file terletak pada skenario di mana Anda menemukan kesalahan dalam aturan pengecualian Anda setelah membuat cadangan dengan aturan itu. Jadi menghapus file pada dasarnya berfungsi sebagai aplikasi retroaktif dari aturan pengecualian. Tampaknya terlepas dari kontroversi di utas ini, semua orang setuju dengan kasus penggunaan khusus itu.

Mengenai operasi di luar itu (yaitu, mengganti nama, menambahkan), saya berbagi keraguan Anda. Ini fitur merayap dan tidak dalam lingkup alat cadangan, IMHO.

Saya setuju: menghapus file dari snapshot itu penting, karena sangat mudah untuk secara tidak sengaja membuat cadangan file yang tidak diinginkan. Ini sering diperlukan untuk alasan keamanan dan penggunaan disk. Memiliki fitur ini dapat berarti perbedaan antara dapat menyimpan data cadangan lama atau harus "membuang bayi dengan air mandi".

Tetapi mengganti nama atau memindahkan file dalam snapshot mungkin bukan ide yang baik. Sejujurnya saya belum pernah mendengar tentang perangkat lunak cadangan yang dapat melakukan ini, dan sepertinya fitur yang aneh. Jika pengguna benar-benar membutuhkan ini, ini dapat diterapkan di luar Restic dengan memulihkan snapshot, mengatur ulang file, dan mencadangkannya lagi dengan tanggal yang ditetapkan secara eksplisit (meskipun ini mungkin menjadi lebih rumit di masa mendatang ketika Restic mulai menggunakan jalur absolut) .

Memang, fitur hapus-jalur-dari-snapshots juga dapat diimplementasikan dengan cara ini, tetapi karena tampaknya lebih mungkin dibutuhkan, saya pikir masuk akal untuk memasukkannya ke dalam Restic.

Jadi, terima kasih atas umpan balik Anda, kami memiliki cara yang jelas ke depan: menerapkan perintah yang memungkinkan menghapus file dari snapshot yang ada. Nama perintah akan diputuskan ketika kita sampai di sana. Kami dapat meninjau kembali kasus penggunaan lain saat diperlukan.

Saya tidak berpikir kita perlu lebih banyak diskusi di sini, terima kasih telah berpartisipasi!

Saran untuk nama perintah: restic purge .

Saya menantikan fitur ini. Terima kasih

@fd0
Adakah pembaruan pada fitur ini? Ingin sekali menggunakannya :)
Kami menggunakan restic di lingkungan pemerintah dan penghapusan satu file dari cadangan diperlukan untuk mereka. Kami dapat mendanai beberapa pekerjaan jika diperlukan!

Saya juga menantikan ini! Saya mengusulkan menggunakan sesuatu seperti struktur dasar untuk restic find .

restic purge [flags] PATTERN

Di mana Anda dapat membatasi purge menjadi host (-H) snapshots (-s) or paths (--path)

Maka mungkin restic prune setelah itu akan melakukan penghapusan yang sebenarnya

Ini akan sangat membantu ketika file yang tidak terduga dicadangkan oleh kesalahan (video besar di folder dokumen atau mungkin beberapa file rahasia) Saat ini, saya menjalankan restic find lalu menghapus setiap snapshot yang berisi file tersebut.. Ini kurang diinginkan jika file jauh di repo (dalam waktu)

Terima kasih !

Tidak ada pembaruan, maaf. Anda akan diberi tahu dengan berlangganan masalah ini jika terjadi sesuatu.

Kedengarannya seperti kebanyakan orang ingin dapat clone metadata cadangan, tetapi mengecualikan file yang menyinggung - tanpa harus mengembalikan semuanya di lokasi awal. Gagasan mengkloning cadangan akan menyalin metadata dengan kemampuan untuk menghapus petunjuk tertentu.

Apakah ini kasus penggunaan?

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite dan modify bisa menjadi makro untuk proses di atas.

Bagi saya, itu sudah cukup @nullcake

Tidak terlalu buruk, @nullcake.

Padahal, berdasarkan pengalaman saya sebelumnya, biasanya saya mendeteksi bahwa saya membuat cadangan banyak barang tidak berharga hanya beberapa hari atau minggu kemudian. Ketika saya punya waktu untuk menyelidiki. Artinya, pada saat saya memahami bahwa saya memerlukan --exclude tertentu, mungkin ada selusin atau lebih cadangan yang terpengaruh.

Tentu saja, bahkan jika pembersihan apa pun diimplementasikan berdasarkan satu cadangan, seperti yang Anda sarankan, itu masih merupakan langkah maju yang bagus. Kami, tentu saja, tahu cara membuat skrip. ;)

Jadi, acungan jempol. :)

Meskipun ini adalah ide yang menarik, saya khawatir perintah backup sudah terlalu rumit, dan menambahkan "sumber" lain untuk cadangan akan semakin memperumitnya. Juga, fungsi ini hanya akan beroperasi pada data yang sudah ada di repo (hanya pada metadata, tepatnya). Perintah terpisah (misalnya purge atau lebih) dapat merangkum fungsionalitas dengan baik.

CrashPlan memiliki perilaku menarik bahwa ketika file dikecualikan, file tersebut akan dihapus dari semua snapshot yang ada. Itu bisa menjadi sesuatu yang perlu dipertimbangkan.

Ini akan menjadi fitur yang bagus. Apakah sudah ditambahkan?

Tidak.

@ fd0 apakah ada kemajuan dalam hal ini? Saya baru tahu bahwa saya tidak mengecualikan cache seperti yang saya kira dan ingin menghapusnya.

Namun saran lain untuk nama perintah: scrub (meskipun saya baik-baik saja dengan purge juga, bendera --rename akan tampak aneh bagi saya). Pikiran saya:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

Di mana --replace=clean menghapus snapshot yang dimodifikasi, prune membersihkan dan menjalankan prune sesudahnya. --diff menunjukkan perbedaan untuk setiap snapshot yang dimodifikasi. --dry-run menghindari melakukan perubahan apa pun pada repo.

Juga valid adalah semua flag --exclude dari restic backup . Saya kira --host dan --time juga masuk akal (masing-masing menggantikan nilai snapshot yang sudah ada sebelumnya); --tag pengeditan sudah ditangani oleh restic tag .

Apakah ada pengembang yang memiliki panduan tentang bagaimana ini dapat diterapkan? Tampaknya bagi saya (dari pandangan sepintas) bahwa sebagian besar kode dapat dimasukkan ke dalam file cmd_scrub.go ; mungkin hanya beberapa tambahan API ke perpustakaan internal yang diperlukan karena tampaknya sebagian besar operasi indeks, tapi mungkin itu naif. Adakah perkiraan kesulitan (saya berasumsi pengujian akan menjadi yang terbesar dalam hal apa pun)?

karena ini adalah masalah yang sangat lama.. apakah ada peluang untuk mendapatkan fitur ini?

Untuk semua yang memantau ini untuk pembaruan dan menekannya dari Google, tidak perlu menunggu masalah ini tidak pernah membuahkan hasil, cukup gunakan duplikat untuk sementara, ia memiliki dukungan kelas satu untuk menghapus file posting fakta dari snapshot.

Untuk semua yang memantau ini untuk pembaruan dan menekannya dari Google, tidak perlu menunggu masalah ini tidak pernah membuahkan hasil, cukup gunakan duplikat untuk sementara, ia memiliki dukungan kelas satu untuk menghapus file posting fakta dari snapshot.

Saya telah menggunakan restic selama sekitar satu tahun sekarang dan saya berhenti menunggu fitur diimplementasikan. Saya tidak bermaksud bahwa semuanya harus ditambahkan ke dalam restic, tetapi ada hal-hal mendasar yang harus ada di sana. Saya sedang mempertimbangkan untuk menjauh dari restic: repositori sangat rapuh dan bisa rusak dengan sangat mudah.

Kemarin saya menghapus snapshot karena menyertakan file yang seharusnya tidak ada di cadangan (saya lupa menambahkan pengecualian). Sejak itu saya memiliki kesalahan dalam repositori saya dan saya belum dapat memperbaikinya. Saya tidak perlu menghapus seluruh snapshot karena beberapa file disertakan secara tidak sengaja.

@MorgothSauron Saya biasanya baru saja menghapus snapshot yang berisi itu juga, yang merupakan satu-satunya solusi yang tampaknya dalam restic, tetapi sekali lagi, duplikati dapat melakukannya melalui satu perintah untuk sementara waktu sekarang, jadi saya telah berubah sejak dan tidak memiliki masalah.

Saya ingin mengucapkan terima kasih kepada semua orang atas masukan mereka tentang masalah ini. Seperti yang telah kita lihat, banyak orang secara khusus menginginkan kemampuan untuk menghapus file dari snapshot. Saya kira kita semua membuat kesalahan sesekali saat membuat cadangan;)

Pada titik ini waktu pengelola dan pengembang yang tersedia diperlukan di bagian restic lainnya, jadi saya tidak memperkirakan masalah ini akan diterapkan di masa mendatang. Saya juga akan merilis server istirahat baru sesegera mungkin, dan kemudian akan mulai melihat beberapa masalah lain.

Yang mengatakan, jika seseorang membuat PR yang solid yang ditulis dengan baik dan jelas, diuji dengan baik dan bebas bug, dan diproduksi dalam koordinasi dengan pengelola, pasti akan dipertimbangkan untuk dimasukkan. Masalah khusus ini adalah masalah di mana @ fd0 telah memberikan restunya pada arahnya, jadi fokusnya dapat terutama pada menghasilkan implementasi yang solid (yang kita tahu tidak akan merusak repo) daripada "haruskah kita menambahkan fitur ini", yang bagus .

PR semacam itu harus menjadi dasar dan bertindak sebagai titik awal yang jika diperlukan dapat dibangun di atasnya. Contoh dari apa yang saya maksud dengan itu adalah sebagai permulaan:

• Hanya menjadi satu perintah baru (misalnya rewrite karena itu yang paling banyak dipilih dalam masalah ini).
• Ambil daftar snapshot sebagai argumen utamanya (termasuk dukungan untuk all ), misalnya all atau 098db9d5 atau 098db9d5 af92db33 .
• Ambil daftar satu atau lebih --exclude <pattern> untuk mendaftar jalur yang harus dikecualikan/dihapus dari snapshot (dengan kata lain, inilah --exclude yang hilang saat mencadangkan), misalnya --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

Alasan di sini adalah untuk mendapatkan awal yang minimal sebagai bukti konsep dan produk yang layak minimum. Setelah diuji, kita dapat menyesuaikannya sesuai kebutuhan, misalnya dengan menambahkan argumen --exclude-* dari perintah backup . Jika kita membuat perintah rewrite seperti ini, ia akan memiliki antarmuka yang hampir sama dengan perintah backup yang dimaksudkan untuk "dikoreksi":

~restic -r /some/repo tulis ulang semua --exclude=" .o" --exclude= .unwanted --exclude=.DS_Storerestic -r /some/repo menulis ulang 098db9d5 af92db33 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Store~

Pada catatan terkait, mungkin pekerjaan yang dilakukan oleh @middelink di https://github.com/restic/restic/issues/323 dapat digunakan sebagai inspirasi atau dasar untuk implementasi, seperti halnya beberapa pemrosesan snapshot yang ada. Aku akan melihat apakah kita bisa bergerak dengan yang satu ini terlalu cepat.

@rawtaz

Terima kasih atas umpan balik yang bijaksana!

Hai, yang di sana.

Saya telah menambahkan implementasi draft rewrite dekat dengan komentar oleh @rawtaz

Ini berfungsi di sini dengan test repo, melewati restic check --read-data tanpa kesalahan, tetapi belum banyak mengujinya. Jadi saya sangat menyarankan untuk tidak menggunakannya dengan data penting.

Saya sudah mencoba untuk mendapatkan sintaks yang sangat dekat dengan perintah backup . Jadi --exclude , --iexclude dan --exclude-file didukung (tetapi tidak diuji). Idealnya saya juga ingin melihat opsi --exclude-if-present (alur kerja yang ideal bagi saya adalah sesuatu seperti 'oops, tidak perlu mencadangkan, tambahkan CACHEDIR.TAG dan restic rewrite '). Tapi itu cukup rumit karena dalam kasus seperti itu kita harus rewrite pada host yang sama di mana cadangan dibuat dan mengakses sistem file untuk mengumpulkan file-file ini (ditambah banyak keajaiban dengan jalur relatif). Jadi tidak sekarang...

Saya juga tidak suka ide untuk mengganti snapshot secara default, jadi perilaku default saat ini adalah membuat snapshot baru dengan tag rewrite . Tetapi penggantian juga dimungkinkan dengan --inplace arg.

Umpan balik apa pun akan sangat dihargai.

Hai Dmitry,

Terima kasih untuk implementasi ini, kerja bagus!

Sejauh ini ia bekerja dengan sempurna di Linux dengan repo uji kecil berisi 600 file + beberapa cuplikan uji. Kembalikan berfungsi dan diff menunjukkan folder yang dikecualikan dengan benar. Saya akan melakukan tes yang lebih intensif pada repo nyata "kloning" dengan banyak GB data dengan lebih dari 100 snapshot. Saya juga akan mencoba repo bersumber Windows.

Satu proposisi : memiliki opsi untuk menentukan tag untuk snapshot yang berisi pengecualian pada pass penulisan ulang. (menjaga tag " rewrite " pada snapshot yang baru dibuat.)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

Ini akan membantu mengidentifikasi snapshot yang masih berisi "_thisfileshouldberemoved.txt_". Di sisi lain, --inplace lebih langsung berfungsi seperti yang diharapkan.

Sekali lagi pekerjaan yang sangat bagus.

@NovacomExperts Ya, motivasi awal saya adalah untuk menjaga 'pengeditan sejarah seaman mungkin. Sangat mudah untuk mengecualikan sesuatu yang penting dengan --exclude * dan hampir tidak ada cara untuk memulihkannya (dengan pencadangan hanya masalah memulai pencadangan baru lagi). Sesuatu seperti --dry-run tetapi dengan kemampuan untuk mendapatkan snapshot aktual dan secara eksplisit menghapus snapshot sumber setelah memeriksa bahwa tidak apa-apa.

Saya sepenuhnya setuju bahwa saat ini hal ini tidak sepenuhnya tercapai. Sangat mudah untuk 'mengamati' snapshot baru, tetapi terlalu sulit untuk menghapus yang lama. Plus saya tidak suka nama snapshot rewrite hardcoded. Mungkin lebih baik memiliki --inplace secara default dan dan ---keep-source-tagged before-rewrite --tag-destination after-rewrite atau sesuatu seperti ini. ( --add-tag agak tidak jelas, apakah itu snapshot lama atau baru).

Bagaimanapun saya akan menunggu umpan balik dari pengelola. Tidak ingin menghabiskan banyak waktu jika bergerak ke arah yang salah.

PS. Repo restic utama saya sekitar ~ 2TB sekarang. Akan mencobanya nanti setelah membuat snapshot LVM.

@dionorgua Motivasi awal Anda sepenuhnya benar. Saya akan memberikan suara saya untuk tetap seperti itu, dengan opsi "berbahaya" --inplace sejauh mungkin dari pengguna (tentu saja tidak secara default). Saya lebih suka kesalahan argumen yang hilang pada --keep-source-tagged / --tag-destination daripada --inplace secara default.

Tapi saya setuju, mari kita tunggu tanggapan tentang ini.

Kemarin, saya lupa repo uji kloning (65 GB) di dalam folder yang dicadangkan oleh restic semalaman. Saya dapat memiliki forget snapshot kemarin tetapi "all in" dan mencoba implementasi Anda. Setelah forget + prune , saya berhasil menghapus 65GB dari repo 400GB. Semua baik, tidak ada kesalahan yang ditemukan.

Saya menguji lebih intensif dengan data yang mencakup beberapa snapshot.

Bersulang

Saya telah mengganti permintaan tarik #2720 yang salah dengan yang baru karena yang lama dibuat dari cabang master. Baru saja menambahkan satu pemeriksaan kesalahan yang hilang. Maaf untuk kebisingan tambahan

Hm, modify lalu?

Sangat terlambat untuk ini, tetapi _rectify_ adalah saran saya untuk perintah delete-specific-file-from-backup.

2731 menarik, terima kasih banyak!

Sangat terlambat untuk ini, tetapi perbaiki adalah saran saya untuk perintah delete-specific-file-from-backup.

Saya harus mengatakan itu bukan nama yang bagus untuk itu. Rectify menyiratkan ada sesuatu yang salah yang perlu dikoreksi/diperbaiki. Meskipun ini mungkin benar dalam salah satu kasus penggunaan, tidak selalu demikian. Seorang pengguna mungkin ingin menghapus beberapa data dari snapshot yang ada untuk mengosongkan ruang untuk semua yang kita ketahui, sambil menyimpan sisa snapshot. Kata-katanya harus lebih netral daripada memperbaiki, saya pikir.