Berdasarkan ini , Anda dapat menggunakan variabel lingkungan RESTIC_PASSWORD untuk menentukan sandi.

Seperti yang sudah dikatakan @pvgoran , Anda dapat menggunakan variabel lingkungan RESTIC_PASSWORD . Ini didokumentasikan dalam manual di sini http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository. Jika Anda memiliki ide tentang bagaimana mendokumentasikan ini dengan lebih baik, silakan buat permintaan-tarik.

Ada juga masalah # 278, yaitu tentang membaca kata sandi dari sebuah file.

Saya akan menutup masalah ini karena tidak ada yang perlu kami lakukan sekarang. Jika Anda tidak setuju, silakan tinggalkan komentar.

Aduh, dan saya pikir saya telah membaca bagian itu secara menyeluruh ....

Mungkin memberi paragraf itu heading atau subheadingnya sendiri? Empat paragraf pertama di bagian itu mencakup segala sesuatu tentang menginisialisasi repositori. Mengotomatiskan cadangan tidak benar-benar sesuai dengan itu.

Terima kasih @pvgoran untuk jawaban cepatnya, btw. :tersenyum:

Hanya pertanyaan tindak lanjut singkat tentang ini. Jika backup tidak selesai pada saat cron menjalankan restic lagi, apa yang akan terjadi?

Dalam hal ini, restic akan memulai pencadangan kedua (paralel), yang menggunakan data yang sudah diunggah oleh pencadangan pertama (masih berjalan). Saya rasa kedua backup akan selesai hampir pada waktu yang bersamaan. Akan ada beberapa duplikasi data, yang akan dibersihkan ketika perintah prune dijalankan lain kali. Itu tidak akan menyebabkan kerusakan data atau kehilangan data. Format repositori dirancang sedemikian rupa sehingga memungkinkan pengunggahan data secara paralel.

Ini adalah kasus menarik yang belum saya pikirkan. Apakah menurut Anda kami memerlukan kode untuk memeriksa apakah cadangan yang sama sudah berjalan di host yang sama, dan dalam kasus ini keluar?

@ fd0 Mungkin, ya. Hanya untuk cadangan yang sama. Atau, cara yang bersih untuk membuat skrip backup otomatis: beberapa instruksi akan dilakukan, mungkin "backup restic" lalu "restic unlock" lalu "restic prune" misalnya. Tetapi tidak perlu khawatir tentang perintah tambahan itu akan menyenangkan.

restic backup diikuti oleh restic forget dan restic prune adalah alur kerja yang biasa, dan itu membersihkannya. Saya akan menambahkan masalah lain, jadi kita bisa melacak ide ini.

Keren terima kasih! Untuk saat ini saya akan menggunakan aliran itu.

Opsi lain di sini yang dapat membantu adalah parameter waktu tunggu. Jika Anda tahu tugas cron Anda menjadwalkan pencadangan setiap X jam, Anda dapat meneruskan --timeout ke restic sehingga akan berakhir sebelum yang berikutnya dimulai. Ini juga akan berguna untuk hal-hal lain juga. (ini mungkin sudah ada, saya baru mengenal restic)

Mendeteksi restic yang sudah berjalan terdengar rumit dan saya tidak bagaimana melakukannya secara akurat dan bersih dari dalam restic itu sendiri. Terutama karena Anda dapat menjalankan backup restic yang berbeda pada saat yang sama yang seharusnya tidak dihitung.

Mungkin skrip start up yang mirip dengan banyak skrip start up linux lainnya yang mengambil PID restic saat dijalankan dan menyimpannya ke file tmp lalu menghapusnya saat restic berakhir. Setiap kali skrip dijalankan, ia akan memeriksa file tersebut. Anda memerlukan file tmp yang berbeda untuk setiap pencadangan terjadwal yang unik.

Sayangnya, cara apa pun untuk mendeteksi instans restic yang sedang berjalan akan gagal di SEMUA backend (SFTP, REST, S3 ...) kecuali yang lokal.

@zcalusic kita dapat menggunakan informasi yang disimpan dalam file kunci untuk melakukan itu: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, mungkin menambahkan daftar file untuk membuat cadangan atau argumen baris perintah yang tepat atau yang serupa.

Saya masih tidak melihat bagaimana restic pada mesin A, menemukan kunci pada mesin backup server B, membedakan antara a) sedang menjalankan sesi restic pada mesin C dan b) stale lock yang tersisa setelah restic pada mesin C crash?

Atau apakah kita mulai berbicara tentang mekanisme RPC di sini? Atau bahkan lebih baik, manajer kunci terdistribusi? 😄

@zcalusic Yang saya bicarakan # 711: mendeteksi kapan pencadangan kedua dengan direktori yang sama pada mesin yang sama dimulai. Itu seharusnya mungkin.

@bwmarrin Saya tidak mengerti apa yang Anda sarankan:

Jika Anda tahu tugas cron Anda menjadwalkan pencadangan setiap X jam, Anda dapat meneruskan --timeout ke restic sehingga akan berakhir sebelum yang berikutnya dimulai.

Entah cadangan dijalankan sampai akhir, atau dibatalkan / dihentikan. Saya tidak berpikir bahwa mungkin untuk entah bagaimana mengatur waktu cadangan yang paling lama membutuhkan durasi berapa pun yang diberikan dalam parameter --timeout hipotetis. Bagaimana itu bisa berhasil?

Bisakah Anda menjelaskan semantik dari parameter seperti itu? Terima kasih!

@ fd0 Saya katakan jika cadangan tidak selesai dalam nilai --timeout, itu dihentikan. Saya menyadari bahwa ini berarti backup tersebut tidak lengkap atau belum selesai. Namun, karena desain inkremental restic, itu bukan masalah besar. Lain kali pencadangan dipanggil, pencadangan akan dimulai dari tempat yang ditinggalkan.

Ini berarti jika Anda memiliki tugas cron yang dijadwalkan untuk dijalankan setiap jam, dan Anda meneruskan parameter --timeout 50m ke restic. Ini akan membatalkan / menghentikan backup jika membutuhkan lebih dari 50 menit. Dalam hal ini, 10 menit kemudian tugas cron akan memulainya lagi dan akan dilanjutkan dari tempat terakhirnya. Ini akan mencegah beberapa contoh dari cadangan yang sama berjalan secara bersamaan.

Terima kasih untuk penjelasannya. Saya pikir ini bukan ide yang bagus. Apa yang terjadi jika lokasi pencadangan lambat tanpa Anda sadari (seseorang di jaringan Anda lupa klien bittorrent, yang memaksimalkan bandwidth upstream Anda), sehingga pencadangan tidak selesai, dibatalkan, dimulai ulang lagi, dibatalkan lagi, dan seterusnya . Maka Anda tidak akan pernah berakhir dengan cadangan yang berfungsi penuh.

Atau pertimbangkan pohon direktori yang datanya terus ditambahkan. Satu run of restic akan selesai pada akhirnya (dirancang seperti itu), tetapi restart restic mungkin tidak akan pernah selesai ketika terlalu banyak data baru ditambahkan di antara run.

Selain itu, Anda dapat dengan mudah mengimplementasikan perilaku ini dengan menggunakan utilitas standar timeout (dari coreutils), dengan menjalankan timeout 40m restic backup [...] . Jadi menurut saya menambahkan opsi ini ke restic adalah ide yang bagus.

Saya menyadari saya terlambat ke pesta tetapi tidak bisakah ada file kunci yang membuat kejadian kedua menunggu yang pertama selesai sebelum dimulai?

@ Karl-Gustav, mungkin Anda dapat mencapainya dengan sedikit skrip. https://stackoverflow.com/a/1985512/244009

Itu sedikit lebih canggih daripada kunci saya :-) Saya hanya menggunakan if file {wait 5sec and check again}

Saya mungkin agak terlambat untuk diskusi tetapi saya membuat beberapa unit systemd yang dapat Anda temukan di sini .
Ini adalah file konfigurasi restic saya, mereka mungkin berguna untuk seseorang.

Halo, saya sedang membaca tentang cara menggunakan restic untuk menjadwalkan pencadangan saya. Untuk saat ini ide saya adalah menggunakan anacron untuk menjadwalkan, misalnya pencadangan 2 hari per minggu ke Backblaze. Intinya adalah, jika backup saya dijadwalkan dengan anacron mis. Selasa dan Jumat jam 12 siang dan laptop saya dimatikan hari Selasa dan tidak memulainya lagi sampai hari Jumat jam 11:59, apa yang akan terjadi? AFAIK (dan jika saya tidak salah) anacron harus memulai pekerjaan yang terlewat pada hari Selasa; dan satu menit kemudian (saat instance restic pertama berjalan), akankah menjalankan backup kedua, menghasilkan 2 backup bersamaan untuk direktori yang sama?

Atau apakah lockfile / tmp jenis apa pun untuk mencegah instance kedua berjalan?
Bagaimana saya harus mengelolanya untuk menjadwalkan pencadangan saya dengan benar? Terima kasih :)

@gerbosch Hai! Pertanyaan ini lebih cocok untuk forum , mohon pertimbangkan itu lain kali :)

Salah satu cara untuk menanganinya adalah dengan menulis skrip yang menjalankan restic untuk Anda, dan sebagai bagian dari melakukan itu membuat runfile (mis. /var/run/restic.pid berisi PID dari proses restic`), yang kemudian dapat periksa apakah restic sudah berfungsi atau belum.

Ini tidak akan menjadi harm dengan cara apa pun jika Anda menjalankan dua pencadangan bersamaan, tetapi tentu saja tidak ada gunanya jika pencadangan tersebut mencakup lebih atau kurang file dan titik waktu yang sama.

Apakah anacron mencoba untuk mengejar backup yang terlewat, saya tidak tahu, itu harus dikatakan dalam dokumentasinya, saya kira. Jika Anda menggunakan macOS dan menggunakan launchd untuk penjadwalan, Anda memiliki opsi untuk melakukannya atau tidak, terserah Anda.

FYI untuk lebih banyak orang yang mendarat di sini dari pencarian Google:

Berikut adalah cara saya melakukan pencadangan sesuai jadwal menggunakan layanan dan waktu systemd, alih-alih pekerjaan cron. Juga menampilkan pemberitahuan email saat pencadangan gagal.

https://github.com/erikw/restic-systemd-automatic-backup

@erikw Skrip jadwal yang fantastis, selamat!
Beberapa pertanyaan:

• Apa keuntungan utama menggunakan timer systemd dibandingkan cron atau anacron?
• Dapatkah skrip / pengaturan systemd diinstal di homedir alih-alih / etc?
• Bisakah tab anacron berada di suatu tempat di $ HOME?

Saya berencana untuk mencadangkan homedir laptop saya, jadi mencadangkan skrip penjadwal yang sama akan disediakan jika terjadi pemulihan bencana, sistem pencadangan terjadwal yang tidak biasa (yaitu memulihkan seluruh cadangan setelah bencana, akan memberikan akun pengguna baru sudah dikonfigurasi untuk melakukan backup pada jadwal sebelumnya yang sama).

@jarangmandi_

• Jika Anda memiliki sistem systemd, cukup menyenangkan dapat menggunakan alat default, tidak perlu menginstal daemon cron. Anda mendapatkan kendali besar atas status pekerjaan yang gagal, dan Anda dapat melihat kapan pekerjaan akan dieksekusi di lain waktu, misalnya. Lihat wiki arch untuk intro singkat. Hanya bermain-main dengannya sendiri adalah cara paling menyenangkan untuk belajar menurut saya.

• Ya, saya menjalankan beberapa timer systemd untuk pengguna lokal saya. Periksa dotfiles saya untuk pengatur waktu dan layanan terkait yang saat ini saya gunakan. Kuncinya adalah menggunakan --user untuk mengontrol pengatur waktu pengguna, bukan pengatur waktu sistem:

$ systemctl --user list-timers

• Sepertinya biasanya mereka berada di /var/spool . Jika bisa dipindahkan ke ~/ saya tidak tahu. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

Karena belum disebutkan di sini, Backupninja adalah cara terbaik untuk menangani penjadwalan. Dukungan restic ditambahkan dalam permintaan penggabungan ; itu hanya belum dilakukan. Semua fungsi dasar harus ada di sana.

@colans Backupninja luar biasa, tidak sabar untuk dapat menggunakannya dengan restic! Terima kasih untuk pekerjaan ini.

restic backup diikuti oleh restic forget dan restic prune adalah alur kerja yang biasa, dan itu membersihkannya. Saya akan menambahkan masalah lain, jadi kita bisa melacak ide ini.

Jika saya menyiapkan tugas harian terjadwal / tugas cron tanpa ekspektasi kemungkinan pekerjaan paralel, apakah skrip harus tetap melakukan restic backup -> restic forget -> restic prune ? Sepertinya itu menambah lebih banyak overhead jika kita hanya mengeksekusi satu instance dalam satu waktu

Bisakah kita membukanya kembali sebagai tugas dokumentasi? Saya pikir kita harus menambahkan bagian "Penjadwalan" ke manual untuk meningkatkan kejelasan seputar topik ini. Kita bisa mengatakan sesuatu seperti:

Penjadwalan berada di luar cakupan Restic. Namun, ada alat eksternal yang dapat digunakan untuk tujuan ini.

• Backupninja bersama dengan cabang pendukung Restic
• Pencadangan restic otomatis menggunakan layanan dan timer systemd
• Konfigurasi cadangan Restic

Pikiran?

Saran lain untuk dibuka kembali. Jika restic tidak mendukung penjadwalan / pemantauan cadangan, dokumen dapat menjelaskan ini dan menautkan ke sesuatu yang mendukung, karena itulah cara utama alat cadangan digunakan.

@SigmaX bagaimana membuat jadwal bergantung sepenuhnya pada OS dan perangkat lunak apa yang Anda miliki. Saya pikir saran seperti itu berada di luar dokumentasi untuk perhatian restic, tetapi itu memang bisa menjadi artikel bermanfaat di blog seseorang atau bahkan di bagian Resep forum. Ini juga bisa menjadi kandidat untuk bagian Contoh di situs web dokumen restic di https://restic.readthedocs.io/en/latest/080_examples.html , tetapi itu harus ditulis sedemikian rupa sehingga membutuhkan minimum pemeliharaan, karena kami tidak ingin menyimpan sekumpulan instruksi terperinci tentang cara menjadwalkannya di beberapa platform berbeda (karena ini adalah topik yang cukup rumit). Semua yang dikatakan, sudah ada beberapa artikel dan contoh tentang ini (misalnya dengan cron dan systemd) di internet, jika seseorang mencarinya. Saya tidak sepenuhnya yakin ada kebutuhan untuk memilikinya di situs web dokumen.

Saya tidak sepenuhnya yakin ada kebutuhan untuk memilikinya di situs web dokumen.

Saya bisa melihat bagaimana ini akan menjadi masalah opini, terutama karena restic adalah lintas platform. Bagi saya, itu mengejutkan. Memiliki alat cadangan tanpa dokumen penting tentang cara menjadwalkannya menurut saya seperti menjual mobil tanpa roda. Saya menghabiskan waktu cukup lama mencari dokumen, dengan asumsi saya melewatkan sesuatu. Saya tidak akan pernah meluncurkan cadangan secara manual, tetapi hanya itu yang dijelaskan oleh dokumen.

Paling tidak, bagian dokumen dapat menghemat waktu pengguna: dengan menunjukkan bahwa mereka perlu mencari di tempat lain / menemukan alat yang berbeda untuk menyiapkan cadangan rutin dengan restic.

Memiliki alat cadangan tanpa dokumen penting tentang cara menjadwalkannya menurut saya seperti menjual mobil tanpa roda

Tidak juga. Apa yang kami "jual" kepada Anda adalah program yang Anda beri tahu apa yang harus dicadangkan, dan program itu mendukungnya. Seberapa sering Anda ingin melakukan itu adalah perhatian tersendiri :) Tapi saya ngelantur.

Saya berharap sebagian besar pengguna jika tidak menemukan topik tertentu di dokumen hanya dengan DDG / Google untuk itu, dan kemudian menemukan jawabannya dalam satu atau dua menit. Tetapi itu tidak berarti kita tidak boleh menambahkan semacam penunjuk ke dokumentasi, bahkan jika kita tidak merinci secara spesifik tentang cara mengatur berbagai perangkat lunak penjadwalan.

Apa yang kami "jual" kepada Anda adalah program yang Anda beri tahu apa yang harus dicadangkan, dan program itu mendukungnya. Seberapa sering Anda ingin melakukannya adalah masalah tersendiri :)

Dan sangat sah untuk mengatakan "ini adalah kit DIY --- cari roda Anda sendiri!"

Saya berharap sebagian besar pengguna jika tidak menemukan topik tertentu di dokumen hanya dengan DDG / Google untuk itu, dan kemudian menemukan jawabannya dalam satu atau dua menit.

Sebenarnya, mencari-cari di Google untuk "jadwal cadangan restic" membawa saya ke sini pertandingan pertama: smile:

2122 terkait karena menyediakan beberapa contoh pengatur waktu systemd dan diskusi lain tentang penjadwalan.

Menurut saya pendekatan "paling sedikit pemeliharaan" di sini tampaknya masuk akal ... mungkin menyertakan petunjuk tentang pencatatan keluaran dan mencegah beberapa proses berjalan pada waktu yang sama?

mungkin menyertakan petunjuk tentang pencatatan keluaran dan mencegah beberapa proses berjalan secara bersamaan?

Saya suka ide itu. Saya akan membuat draf akhir minggu ini, kemungkinan besar untuk bagian "penunjuk" kecil untuk ditempatkan di bawah bagian pencadangan dalam dokumentasi.