Restic: Abaikan pembuatan snapshot jika tidak ada perubahan

Mungkin ide yang bagus untuk tetap membuat semacam nama alias.

Kita perlu mendefinisikan apa yang dimaksud dengan "tidak ada perubahan": "Tidak ada file yang ditambahkan/dihapus dan tidak ada file yang memiliki konten berbeda" dan/atau "tidak ada metadata dan tidak ada konten yang berubah".

Seperti yang dibahas di IRC: Tidak membuat snapshot baru dapat mengganggu kebijakan forget ...

Saya ingin tahu: Mengapa Anda membutuhkan fungsi ini? Apa kasus penggunaan Anda?

Saya ingin tahu: Mengapa Anda membutuhkan fungsi ini? Apa kasus penggunaan Anda?

Saya hanya merasa tidak perlu mengacaukan repo dengan snapshot yang tidak berguna bagi saya.
Kasus penggunaan saya adalah sekumpulan file yang ingin saya cadangkan seperti dua kali sehari tetapi tidak sering berubah (sebulan sekali, bahkan mungkin kurang dari itu). Itu akan meninggalkan saya dengan ~59 snapshot "kosong" sebulan di repo saya mungkin memperlambat operasi (karena ini adalah repositori jarak jauh dengan waktu pulang pergi yang tinggi). Saya dapat menjalankan forget & prune secara teratur tetapi itu akan memakan biaya perjalanan pulang pergi serta panggilan API dll.

Semua dalam semua ini adalah penyebab "bagus untuk dimiliki" karena ada banyak cara untuk mengatasi ini (atau lebih baik: menggunakan restic :smiley: dengan benar). Saya hanya ingin membicarakannya saat saya memikirkannya dan mungkin juga orang lain.

Terima kasih untuk penjelasannya. Apa yang saya pikirkan ketika membangun restic dan struktur repositori adalah bahwa "snapshot" menangkap keadaan data pada satu titik waktu. Jika data tidak berubah sama sekali dibandingkan dengan snapshot sebelumnya, snapshot tambahan sangat murah dan hanya menggunakan beberapa ratus byte dan satu file tambahan di repositori. Anda benar bahwa lebih banyak snapshot dapat memperlambat operasi sedikit, terutama untuk backend jarak jauh latensi tinggi, tetapi saya yakin efek ini dapat diabaikan. Kalau belum tentu bisa kita optimalkan (bandingkan #523), tapi saya mau ukur/benchmark dulu untuk mendapatkan hard data :)

Saya akan menutup masalah ini untuk saat ini, Anda masih dapat menambahkan komentar (dan kami dapat dengan mudah membukanya kembali nanti).

Hai, pengguna restic pertama kali di sini, mencobanya. Ini terlihat hebat sejauh ini.
Namun, saya cukup terkejut restic membuat snapshot kosong jika tidak ada yang berubah dan terlebih lagi tidak ada tanda untuk melewati pembuatan jika tidak ada perubahan.
Sebagai pengguna pertama kali, saya mengharapkan ini (yaitu melewatkan snapshot kosong) menjadi perilaku default, atau setidaknya memiliki opsi untuk itu. Membuat snapshot kosong berlawanan dengan intuisi saya, saya tidak benar-benar melihat tujuannya (sekali lagi: pengguna pertama kali, ini adalah reaksi naluriah pertama saya).

Membaca log obrolan IRC sepertinya tidak akan banyak usaha untuk menambahkan ini. Bisakah ini ditambahkan sebagai tanda ke cadangan, sehingga pengguna setidaknya bisa punya pilihan?

Meskipun saya sendiri tidak pernah menggunakan opsi seperti itu, saya ingin menjawab pertanyaan apa artinya 'tidak ada perubahan'.

@fd0 menyatakan

"Tidak ada file yang ditambahkan/dihapus dan tidak ada file yang memiliki konten berbeda" dan/atau "tidak ada metadata dan tidak ada konten yang berubah".

IMHO satu-satunya pilihan yang valid di sini adalah pilihan "DAN":

• Tidak ada node (dir, file, symlink, perangkat, perangkat khusus, dll.) yang ditambahkan atau dihapus, DAN
• Tidak ada file yang memiliki konten berbeda, DAN
• Tidak ada metadata (izin, pemilik, grup, ctime, mtime, dll.) yang diubah

Pada pandangan pertama saya mengira ada beberapa redundansi untuk ini, karena biasanya setiap perubahan konten juga akan menyebabkan perubahan mtime. Tetapi setelah dipikir-pikir selalu ada alat untuk mengatur ctime/mtime secara eksplisit sehingga tidak hanya memeriksa konten saja, atau hanya memeriksa metadata saja sudah cukup.
Saya tidak 100% sadar tentang semantik atime tetapi dengan ekstrapolasi saya akan mengatakan hal yang sama harus berlaku, jadi harus berhati-hati untuk mengembalikan atime setelah restic membaca file untuk memeriksa isinya.

Saya yakin ada beberapa masalah yang meminta pengumpulan statistik selama pencadangan (mis. #693, #874). Saya kira kode pengumpulan statistik yang diperlukan untuk mereka juga akan berguna di sini.

@ignus2 terima kasih telah menjelaskan harapan dan reaksi Anda, itu sangat berharga bagi kami sebagai sebuah proyek!

Snapshot restic lebih dapat dibandingkan dengan "snapshot mesin virtual" atau "snapshot sistem file lvm/zfs" daripada misalnya file tar dari apa yang telah berubah. Jika tidak ada yang berubah, snapshot masih dibuat untuk merekam "ini adalah status saat ini" pada titik waktu tertentu. Mungkin kita harus menambahkannya ke manual.

Jadi, apakah mungkin menambahkan tanda untuk melewati pembuatan snapshot jika tidak ada yang berubah?

Dimungkinkan untuk menambahkan ini, tetapi saya rasa kita tidak akan menambahkannya: Ini bukan cara kerja restic dan akan menyebabkan masalah saat Anda menggunakan perintah forget .

Itu tidak akan mengubah cara restic bekerja secara default, karena itu akan menjadi flag opsional . Masalah apa yang akan ditimbulkannya dengan perintah forget btw?

Jalur kode opsional perlu diuji dan dipelihara juga! Jadi, ini menciptakan utang teknis berkelanjutan untuk fitur yang agak tidak biasa.

Saya tidak ingat: apakah Anda menjelaskan mengapa memiliki snapshot "kosong" adalah masalah untuk kasus penggunaan Anda?

--
Michael L. Barrow
michael di barrow dot me
+1,541-600-2027

Pada 11 Oktober 2017, pukul 06:04, Balázs Oroszi [email protected] menulis:

Itu tidak akan mengubah cara kerja restic, karena itu akan menjadi flag opsional. Masalah apa yang akan ditimbulkannya dengan perintah forget btw?

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

Gagasan di balik perintah forget (seperti yang dijelaskan misalnya dalam entri blog ini ) adalah Anda menentukan kebijakan untuk snapshot yang ingin Anda pertahankan. Jika Anda hanya memiliki snapshot ketika data telah berubah, menentukan misalnya --keep-daily tidak masuk akal lagi.

Benar-benar tidak ada yang namanya snapshot "kosong" dalam restic. Setiap snapshot menangkap data dan metadata pada titik waktu tertentu dan independen (mengenai struktur data) dari semua snapshot lainnya.

Btw, jika Anda benar-benar ingin melakukan itu, Anda bisa menggunakan restic snapshots --json , lalu ambil ID snapshot, gunakan restic cat snapshot <id> untuk masing-masing dan lepaskan yang di mana ID pohonnya tidak berubah. Itu sama dengan menghapus snapshot "kosong".

Ya, saya tahu mereka tidak kosong. Saya hanya menggunakan istilah itu untuk menggambarkan mereka lebih dekat per skenario khusus ini; "kosong" menyiratkan sedikit atau tidak ada nilai pada OP berdasarkan kriteria tidak ada file yang berubah.

--
Michael L. Barrow
michael di barrow dot me
+1,541-600-2027

Pada 11 Oktober 2017, pukul 07:30, Alexander Neumann [email protected] menulis:

Ide di balik perintah forget (seperti yang dijelaskan misalnya dalam entri blog ini) adalah Anda menentukan kebijakan untuk snapshot yang ingin Anda pertahankan. Jika Anda hanya memiliki snapshot ketika data telah berubah, menentukan misalnya --keep-daily tidak masuk akal lagi.

Benar-benar tidak ada yang namanya snapshot "kosong" dalam restic. Setiap snapshot menangkap data dan metadata pada titik waktu tertentu dan independen (mengenai struktur data) dari semua snapshot lainnya.

Btw, jika Anda benar-benar ingin melakukan itu, Anda bisa menggunakan snapshot restic --json, lalu ambil ID snapshot, gunakan snapshot restic catuntuk masing-masing dan jatuhkan yang di mana ID pohon tidak berubah. Itu sama dengan menghapus snapshot "kosong".

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

Saya akan membuka kembali masalah ini.

Apa yang "tidak biasa" adalah masalah pendapat yang saya yakini, bagi saya memiliki snapshot "kosong" (menurut definisi "memiliki sedikit atau tidak ada nilai berdasarkan kriteria tidak ada file dan metadatanya berubah") tidak biasa.

Mengenai kebijakan lupa, saya tidak melihat bagaimana hal itu akan mengganggu. Misalnya menjalankan pencadangan restic sesekali (mungkin tergantung pada cara lain untuk menentukan apakah sesuatu berubah dan pencadangan perlu dibuat atau tidak) akan memiliki efek yang sama seperti melewatkan pembuatan snapshot, dalam hal ini lupa juga tidak masuk akal seperti Anda menulis.

Saya ingin tekankan lagi, bahwa ini akan menjadi fitur opsional bagi mereka yang ingin menggunakan restic dengan cara yang sedikit berbeda, yang mungkin tidak akan pernah menggunakan fitur keep-daily dll. lupa sama sekali.

Terima kasih telah menyebutkan solusi btw.

Saya ingin tahu: Apakah perangkat lunak pencadangan lain biasanya memiliki opsi seperti itu?

Saya ingin tahu: Apakah perangkat lunak pencadangan lain biasanya memiliki opsi seperti itu?

Saya tidak tahu, tetapi jika demikian, maka restic juga harus, jika tidak, restic bisa menjadi unik dalam hal ini;)

BTW, sepertinya saya memahami penolakan terhadap fitur ini, karena restic menekankan pada "kapan" atau "waktu" cadangan (juga ditunjukkan dengan cara kerja lupa, berpusat di sekitar waktu), maka snapshot tepat waktu. Sementara use case yang ada dalam pikiran saya (dan mungkin OP juga) lebih menekankan pada "perubahan" dengan tambahan informasi sampingan "kapan".

EDIT: Sesuatu seperti git, atau sedang memikirkan restic seperti cara kerja git (dari sudut pandang pengguna akhir) adalah ide yang sangat buruk?

IMHO, "kecerdasan" semacam ini tidak memiliki tempat di perangkat lunak cadangan. Jika saya meminta perangkat lunak cadangan untuk melakukan pencadangan, saya ingin itu tidak bermain game di belakang saya, memiliki pendapat sendiri, tidak ada yang berubah dll ... Jadi, besok saya garuk-garuk kepala mencari cadangan semalam, yang tidak ada?!

Mari kita sederhanakan, jika tidak ada yang baru untuk di-backup, yah.. maka jangan backup! Putuskan perangkat lunak cadangan luar, lalu kirim cadangan atau tidak. Perangkat lunak pencadangan yang terlalu pintar akan menjadi perangkat lunak pencadangan yang tidak dapat diandalkan. Saya ingin itu dapat diandalkan, tidak terlalu pintar, jika memungkinkan.

Saya belum pernah melihat ini, itulah sebabnya saya menggunakan "tidak biasa" untuk menggambarkan ini
fitur dalam pesan saya sebelumnya.

Alasan lain mengapa itu tidak biasa adalah karena bertentangan dengan konsep
dari solusi perlindungan data. Snapshot mewakili keadaan
dunia pada waktu itu (lihat kembali penjelasan tentang fakta bahwa
snapshot tidak benar-benar kosong).

Jika snapshot tidak dihapus, akan sulit untuk mengetahui apakah snapshot tersebut
benar-benar terjadi dan dianggap tidak diperlukan oleh kriteria ini, atau jika
sistem gagal.

michael di barrow dot me
+1.541.600.2027

"Jangan mengantisipasi masalah, atau
khawatir tentang apa yang mungkin tidak akan pernah terjadi.
Tetap di bawah sinar matahari." -- B. Franklin

Pada Wed, 11 Oktober 2017 di 08:31, Balázs Oroszi [email protected]
menulis:

Saya ingin tahu: Apakah perangkat lunak pencadangan lain biasanya memiliki opsi seperti itu?
Saya tidak tahu, tetapi jika demikian, maka istirahat juga harus, jika tidak, istirahat bisa
unik dalam hal ini ;)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/restic/restic/issues/662#issuecomment-335850739 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/ABzVspDVasI91Mp4B2hFCMlsCWGr_B-Vks5srN9IgaJpZM4KrXNh
.

@zcalusic " opsional _, jadi hanya pengguna yang akan terpengaruh olehnya yang secara khusus memintanya.

@ignus2 : Saya mengerti, tetapi kode apa pun yang ditambahkan ke basis kode perlu diuji dan dipelihara dari waktu ke waktu. Plus, tampaknya permintaan Anda sangat unik.

Cara lain untuk mencapai status akhir Anda adalah dengan meningkatkan RPO (Tujuan Titik Pemulihan). Dengan kata lain, jika Anda tahu bahwa data Anda berubah lebih jarang, jangan repot-repot membuat snapshot lebih sering.

Saya mendukung komentar @ ignus2 tentang sakelar opsional.
Jelas ada kasus penggunaan restic yang sangat berbeda.

Beberapa ingin melakukan pencadangan "tradisional", katakanlah setiap hari, katakanlah untuk banyak file, dan dapat memulihkan keadaan hari X jika sesuatu yang buruk terjadi pada X+1. Mereka tahu waktu ketika data dihancurkan.
Pengguna tersebut fokus pada pemulihan status pada tanggal tertentu . Mereka tidak pernah ingin melewatkan snapshot.

Orang lain (seperti saya) ingin menggunakan restic untuk memotret keadaan folder cukup sering, mungkin setiap 30 menit. Status pada tanggal tertentu tidak penting, mungkin mereka tidak tahu kapan data rusak (mis. sinkronisasi file). Sebaliknya mereka ingin cepat melihat jika/kapan ada perubahan (misalnya untuk dapat melacak titik di mana korupsi data terjadi dengan perbedaan sesedikit mungkin).
Pengguna tersebut fokus pada titik waktu di mana perubahan terjadi. Snapshot tanpa perubahan hanyalah gangguan bagi mereka (misalnya saat memasang cadangan untuk melakukan perbedaan antara setiap dua snapshot yang berdekatan).

Apa yang Anda gambarkan terdengar seperti Anda mencoba menggunakan restic sebagai semacam sistem kontrol revisi, bukan?

Saya pikir tidak relevan bagaimana menyebutnya, use case didefinisikan dengan jelas di atas, adalah sah, restic lebih dari mampu untuk mendukung use case itu bahkan sekarang, tetapi solusi manual harus digunakan (daftar snapshot, periksa treeid dengan sebelumnya, hapus jika sama, pangkas), memiliki sakelar _ opsional _ bawaan untuk mendukung kasus penggunaan ini akan membuatnya jauh lebih baik dan didukung secara langsung.

Nah -- Anda memiliki sumbernya. Hancurkan dirimu!

Dalam hal ini dapatkah Anda membantu kira-kira modifikasi apa yang diperlukan (seperti pada gambaran umum) dan apa yang harus diperhatikan saat menerapkan fitur ini? Terima kasih sebelumnya.

Tolong jangan bekerja pada fitur ini untuk saat ini, saya ingin mengerjakan ulang kode pengarsipan terlebih dahulu.

Saya ingin mencoba lagi dan menjelaskan reservasi saya sehubungan dengan perintah forget lagi, saya pikir itu tidak cukup jelas.

Misalkan kita memiliki pengguna yang menjalankan restic backup setiap 30 menit secara otomatis (misalnya melalui cron). Pada hari berikutnya, mereka menjalankan restic forget --keep-hourly 24 .

Saat ini, repositori akan berisi 24 snapshot, satu untuk setiap jam dari hari sebelumnya.

Dengan mengaktifkan fitur ini (hanya menyimpan snapshot di mana data diubah), hasilnya dapat sangat bervariasi: Repositori akan tetap berisi hingga 24 snapshot, paling banyak satu per jam, tetapi mungkin ada snapshot dari minggu lalu, diikuti satu dari dua hari sebelumnya. Tahukah Anda bahwa forget bekerja dengan cara ini?

Yang mengganggu saya adalah forget menjadi sangat tidak terduga.

Jadi, untuk saat ini kami membiarkan masalah ini terbuka.

Orang yang membaca masalah ini : Jika Anda memiliki kasus penggunaan yang belum dijelaskan (yaitu menggunakan restic sebagai semacam sistem "kontrol versi"), silakan tambahkan komentar.

Jika tidak, tolong jangan tambahkan komentar lebih lanjut untuk saat ini.

Terima kasih!

OK, meskipun saya sudah menerapkan versi dasar sebagai percobaan pertama dan berfungsi dengan baik (praktis 7 baris kode).

Mengenai komentar Anda tentang perintah forget : tidak relevan di sini. Saya pikir itu tidak jelas dari penjelasan @maxhq : mode operasi atau flag ini (yaitu melewatkan snapshot tanpa perubahan) tidak untuk digunakan dan tidak masuk akal dalam kasus penggunaan yang melibatkan forget perintah. Cara yang sama perintah forget tidak masuk akal dalam kasus penggunaan di mana melewatkan snapshot terlibat.

Untuk lebih jelas: pengguna yang ingin dan perlu menggunakan perintah forget tidak akan dan tidak boleh menggunakan restic backup dengan flag yang melewatkan snapshot tanpa perubahan, dan sebaliknya.

Kode proof-of-concept ada di komit ignus2/ restic@7ebee9de1838e3d3954ecd36d43db499dd508a17 jika ada yang tertarik.

Jika tidak, tolong jangan tambahkan komentar lebih lanjut untuk saat ini.

@fd0 kenapa tidak?

Saya ingin menjelajahi sedikit implikasi dari forget .

Jika Anda hanya memiliki snapshot ketika data telah berubah, menentukan misalnya --keep-daily tidak masuk akal lagi.

Sangat mungkin saya salah memahami sesuatu, saya cukup baru dalam restic , tetapi bagi saya kedengarannya sebaliknya. Saya akan mengikuti deskripsi ini di posting blog yang Anda sebutkan:

Ketika --keep-daily disetel, misalnya ke nilai 7, maka restic akan menerapkan pendekatan yang serupa ke --keep-hourly : Telusuri daftar, temukan tujuh hari terakhir di mana setidaknya satu snapshot dibuat. Untuk setiap hari, simpan snapshot terakhir yang dibuat pada hari itu, tandai yang lain untuk dihapus, dan hapus semua snapshot dari daftar.

Mari kita periksa terakhir, katakanlah 14 hari, dan snapshot mana yang akan dan tidak akan ditampilkan tergantung pada apakah kita membuat snapshot duplikat atau tidak, dan snapshot mana yang akan dihapus / tetap tidak terhapus oleh --keep-daily .

Demi argumen, katakanlah snapshot diambil setiap jam di our. Hari ini adalah 23:30 pada tanggal 14 setiap bulan. Mari kita asumsikan bahwa data tidak sering berubah: Itu berubah beberapa kali pada tanggal 1, 2, 3, 4, 5, 6 dan 13 setiap bulan. Jika kita menjalankan forget dengan --keep-daily diatur, misalnya ke nilai 7 kita berakhir dengan 7 snapshot yang 5 di antaranya akan identik, yang menurut saya tidak terlalu berguna. Sebaliknya, jika kita tidak merekam snapshot yang sama berulang-ulang, semua 7 snapshot akan berbeda, yang, menurut IMO, jauh lebih berguna. Sebenarnya saya tidak tahu, mengapa Anda mungkin ingin menyimpan 6 snapshot yang identik, itu tidak menambah nilai sejauh yang saya bisa melihatnya.

Saya tidak yakin bagaimana dengan skenario ini yang "tidak dapat diprediksi" Anda masih akan mendapatkan 7 snapshot terakhir Anda, hanya saja mereka semua akan menjadi snapshot yang berbeda alih-alih mengulangi yang, seperti yang telah saya sebutkan tampaknya lebih berguna.

Bisakah Anda mengartikulasikan kekhawatiran Anda sedikit lebih banyak, sehingga kami dapat mencari jalan ke depan. Jika menyangkut kesadaran, maka perubahan ini bisa dilakukan bersamaan dengan perubahan dokumentasi, dan tentunya harus menjadi pilihan.

Pertanyaan: apa gunanya memiliki snapshot yang identik? Bagaimana itu berguna?

Sebenarnya saya punya saran alternatif untuk posting asli, yang akan memuaskan saya, dan bisa lebih menarik bagi para pengembang yang menyuarakan keprihatinan mereka: alih-alih menambahkan opsi untuk tidak membuat snapshot, tambahkan kebijakan forget untuk menemukan dan hapus semua snapshot yang identik kecuali yang terbaru, di setiap kumpulan snapshot yang identik (jika ini dapat dilakukan dengan cara yang baik). Saya tidak keberatan menjadwalkan perintah lupa tambahan setelah pencadangan untuk menghapus snapshot terakhir itu jika itu duplikat. Ini bisa menjadi yang terbaik dari kedua dunia.

Karena persyaratan ruang harus cukup rendah karena deduplikasi, itu akan banyak membantu saya jika snapshot identik terdeteksi dan properti/tag tambahan disimpan. Dengan cara ini orang dapat memfilter daftar snapshot untuk menyembunyikan duplikat sambil menyimpannya untuk referensi (memberikan informasi bahwa pencadangan masih dilakukan dengan benar dan tidak ada masalah dengan penjadwalan/skrip, dll.).