Restic: Cadangan tidak terenkripsi

Saya telah mendengar permintaan fitur ini beberapa kali sekarang, dan saya berpikir bahwa ada masalah tentang itu. Karena sepertinya saya tidak dapat menemukannya, permintaan fitur ini dilacak di sini. Versi singkatnya adalah: Kami mungkin pada akhirnya menambahkan opsi untuk menonaktifkan enkripsi, tetapi itu tidak ada di peta jalan saat ini.

Versi panjangnya adalah:

• Enkripsi tidak lagi mahal, setidaknya tidak jika Anda memiliki AES-NI (enkripsi yang dipercepat perangkat keras), yang cukup umum saat ini (setidaknya di laptop dan server)
• restic tidak hanya peduli tentang enkripsi, tetapi juga tentang keaslian dan penandatanganan data. Kami perlu menemukan cara untuk menerapkan ini tanpa enkripsi, jadi kami tetap harus menyimpan kunci/sandi.
• Setelah kami memiliki jalur kode yang memungkinkan pencadangan tidak terenkripsi, ada kemungkinan penyerang menemukan cara untuk mengelabui klien agar menyimpan data tanpa enkripsi ke dalam repositori terenkripsi (awalnya). Itu terjadi dengan program cadangan lain sebelumnya, jadi kami harus sangat berhati-hati, yang membutuhkan waktu dan sumber daya yang tidak kami miliki saat ini.

Saya dapat menambahkan poin lebih lanjut ketika saya menemukannya.

Alasan alternatif untuk menginginkan cadangan yang tidak terenkripsi (secara lokal) adalah agar repositori pusat dapat dibagikan oleh banyak pengguna - yaitu di server rumah saya, saya ingin mengirim cadangan ke sana melalui HTTPS, tetapi biarkan semuanya dideduplikasi menjadi repositori umum, bahkan jika mereka disajikan sebagai terpisah secara logis untuk pengguna individu.

ada kemungkinan penyerang menemukan cara untuk mengelabui klien agar menyimpan data tanpa enkripsi ke dalam repositori terenkripsi (awalnya).

Hm, saya pikir idenya adalah bahwa repositori dienkripsi atau tidak, jadi tidak mungkin menyimpan data yang tidak terenkripsi ke dalam repositori yang dienkripsi ... Dan jika repositori terenkripsi entah bagaimana diganti dengan yang tidak terenkripsi dengan yang sama nama dan lokasi, pengguna harus memperhatikan bahwa tidak ada kata sandi yang diminta. Mungkin peringatan dalam teks berkedip merah tebal dapat dicetak, bahwa repositori tidak terenkripsi :).

@wrouesnel Anda sudah bisa melakukannya, membedakan dengan nama host! (Saya bertanya-tanya hal yang sama tempo hari) :)

@alexeymuranov bagaimana Anda menentukan apakah kata sandi yang dimasukkan oleh pengguna adalah kata sandi enkripsi untuk direktori terenkripsi, atau kata sandi MAC untuk memverifikasi keaslian direktori yang tidak terenkripsi? lebih --switches ? Ini menjadi sangat berantakan sangat cepat.

Saya ingin memiliki opsi ini untuk membuat cadangan lokal. Misalnya, setiap hari saya menjalankan cadangan direktori ~/Music saya di server saya, tetapi saya tidak memerlukannya untuk dienkripsi. Cadangan bukan untuk melindungi dari kegagalan atau kehilangan perangkat keras (saya punya cadangan lain untuk itu), tetapi hanya untuk melindungi dari kecelakaan dan bitrot. Dan servernya agak bertenaga rendah, jadi overhead enkripsi menjadi masalah.

@alphapapa untuk itu ada rsync .
EDIT: Dan izin file/atribut. BTW, apa perbedaan antara "kegagalan perangkat keras" dan "bitrot"?

@cfcs , rsync tidak menghapus duplikat .

untuk itu ada rsync.

@cfcs Seperti yang kita semua tahu, cermin bukan cadangan. ;) Menggunakan Obnam, saya menyimpan serangkaian cadangan, mirip dengan restic: keep = 7d,8w,12m,3y Sejak saya hampir kehilangan kunci GPG saya (karena secara misterius terpotong menjadi 0 byte tanpa saya sadari, dan file yang terpotong telah dicadangkan berulang kali), dan saya harus menggalinya dari cadangan lama di CD-R, saya menyadari pentingnya menyimpan data cadangan lama.

BTW, apa perbedaan antara "kegagalan perangkat keras" dan "bitrot"?

Bitrot biasanya tidak terdeteksi sampai Anda membutuhkan data busuk, dan tidak membuat seluruh perangkat tidak dapat dibaca. Kegagalan perangkat keras adalah, misalnya disk benar-benar gagal, sistem gagal untuk boot, dll.

Dan seperti yang ditunjukkan Alexey, rsync tidak menghapus duplikat, juga tidak menyediakan pemangkasan data cadangan lama, atau pemeriksaan integritas data, dll. rsync adalah alat yang bagus, dan saya menggunakannya secara teratur, tetapi tidak untuk membuat cadangan .

Enkripsi tidak lagi mahal, setidaknya tidak jika Anda memiliki AES-NI (enkripsi yang dipercepat perangkat keras), yang cukup umum saat ini (setidaknya di laptop dan server)

Kecuali jika perangkat lunak Anda ditulis dalam go. Crypro Go adalah perangkat lunak hanya untuk apa pun kecuali intel - jadi dengan perangkat lengan Anda terjebak dengan "perkiraan waktu pencadangan - 14 hari" untuk kumpulan file yang sama yang diselesaikan dalam waktu kurang dari 30 menit dengan solusi pencadangan berbasis openssl resmi di NAS saya .

Saya juga ingin melihat fitur ini. Saya menggunakan SSH untuk transfer dan saya menyimpan cadangan saya di LUKS/cryptsetup volume terenkripsi, jadi enkripsi hanya menambah risiko kehilangan kunci enkripsi. Juga enkripsi menambahkan lebih banyak kesalahan dan menambahkan beban yang tidak perlu ke CPU.

Namun enkripsi sangat berguna, ketika saya mencadangkan ke target yang tidak tepercaya.

Orang mungkin termotivasi untuk mengamankan file teks termasuk kata sandi bersama dengan cadangan...

Saya juga menggunakan target cadangan terenkripsi luks/dm-crypt. Ini adalah disk USB eksternal yang saya pasang ke /Backup/
Anda bisa membuat file kata sandi di lokasi itu (/Backup/restic_password) dan memasukkannya ke restic dengan menggunakan --password-file. Repositori berada di bawah /Backup/restic_repo/
Penting untuk membuat file kata sandi tidak dapat diubah, atau Anda akan bingung jika hilang secara tidak sengaja: chattr +i /Backup/restic_password
Saya juga hanya menggunakan "restic" sebagai kata sandi, untuk berjaga-jaga.

Fitur enkripsi Restic sangat berguna jika Anda mencadangkan ke target yang tidak tepercaya seperti penyedia cloud. Tetapi jika Anda hanya menggunakan drive eksternal yang Anda simpan di rumah, atau NAS di ruang bawah tanah Anda, enkripsi paksa agak gila. Rata-rata pengguna akan lupa password pula.

Mengizinkan pencadangan yang tidak terenkripsi akan memungkinkan ZFS atau BtrFS atau NTFS atau sistem file apa pun untuk mengompresi cadangan.

(Enkripsi dapat dilakukan melalui dmcrypt di lapisan bawah jika diinginkan)

Mengizinkan pencadangan yang tidak terenkripsi akan memungkinkan ZFS atau BtrFS atau NTFS atau sistem file apa pun untuk mengompresi cadangan.

Sama di sini, tidak ada kompresi dan enkripsi wajib yang memakan terlalu banyak ruang di server cadangan saya. Kasus penggunaan saya (beberapa gambar, banyak file kecil xml/txt/csv) akan sangat diuntungkan baik dari tanpa enkripsi (sehingga ZFS dapat melakukan hal itu) atau kompresi (~ 2,3 rasio kompresi dengan zstd,5).

Jika Anda menggunakan ZFS, mengapa tidak menggunakan snapshot zfs send ?

Snapshot ZFS tidak cukup untuk cadangan dalam banyak kasus. Jika Anda memiliki korupsi yang tidak terdeteksi dalam sebuah file, atau jika Anda ingin menyimpan set bernilai bertahun-tahun, snapshot ZFS tidak banyak membantu. Misalnya, Anda menggunakan FreeNAS dan ingin mempertahankan cadangan mingguan selama satu tahun. Penjadwalan dan manajemen snapshot yang dibangun ke dalam FreeNAS tidak _benar-benar_ cukup untuk melakukannya dengan benar. Ini bukan "perusahaan".

Jika Anda memiliki sistem penjadwalan yang lebih rumit, itu mungkin akan bekerja jauh lebih baik. Ada juga masalah pengiriman zfs yang membutuhkan snapshot sebelum Anda dapat mengirimkannya; Anda juga harus mengelola jadwal snapshot dan memastikan snapshot dan jadwal pengiriman Anda disinkronkan (secara manual) sehingga Anda menekan RTO/RPO Anda.

Dan ya.. saya sedang berbicara tentang fitur perusahaan di FreeNAS. Tapi itulah kekhawatiran...

Enkripsi tidak mahal lagi, setidaknya tidak jika Anda memiliki AES-NI

Persyaratan AES-NI mengecualikan banyak server lama (yang dalam beberapa kasus _sangat penting_ untuk dicadangkan!).

Saya membantu seseorang mendapatkan beberapa cadangan yang lebih baik yang berjalan di kumpulan server di pedesaan Afrika, pada perangkat keras yang disumbangkan berusia 10+ tahun (beberapa di antaranya bahkan masih 32-bit!). Saya khawatir enkripsi hanya akan menambah terlalu banyak overhead, jadi saya kira untuk saat ini saya perlu mencari di tempat lain.

+1 tanpa enkripsi

ini akan berguna

+1 tanpa enkripsi

ini akan berguna

Harap gunakan fitur jempol ke atas pada edisi asli alih-alih memberi '+1' untuk menghindari membanjiri kotak masuk pengamat. Terima kasih!

Apa status fitur ini?

Saya perlu mencadangkan file (dokumen bersama seperti terjemahan manual pengguna) dari server samba internal yang dapat diakses oleh semua pengguna di perusahaan, mereka tidak terlalu rahasia dalam batas-batas perusahaan. Enkripsi cadangan dalam hal ini tidak ada gunanya, saya tetap menggunakan jailkit untuk keamanan tambahan untuk cadangan, dan saya menggunakan sistem file btrfs dengan kompresi yang diaktifkan. Saya membuat cadangan hal-hal seperti dump disk VM dengan cara lain. Enkripsi bukan masalah dalam kasus penggunaan saya, mencegah kehilangan data adalah satu-satunya prioritas. Menggunakan kata sandi seperti 'restic' adalah solusi yang konyol.

Silakan terapkan ini.

@mrkafk Apa masalah sebenarnya bagi Anda dengan restic yang memiliki enkripsi? Bahkan jika Anda tidak membutuhkannya, Anda memerlukan alasan yang sangat spesifik untuk menjadi masalah, karena CPU Anda kemungkinan besar memiliki dukungan untuk enkripsi perangkat keras.

Saya telah menjelaskan masalah saya yang sebenarnya: mengingat konteks spesifik saya tidak membutuhkannya, sementara seperti yang saya mengerti setidaknya menghilangkan keuntungan kompresi dalam sistem file btrfs. Saya punya banyak file untuk dicadangkan, itu sebabnya saya menggunakan btrfs dengan kompresi diaktifkan sejak awal karena dengan RAID-1 untuk redundansi hw saya membutuhkan banyak ruang disk (jika bukan karena itu, saya lebih suka menggunakan ext4). Juga, mengenkripsi dengan kata sandi palsu dan melakukan enkripsi yang tidak perlu terasa ... konyol.

Oke, dari hal-hal yang Anda tulis, saya mengumpulkan satu masalah sebenarnya , yaitu kompresi BTRFS tidak seefektif mungkin tanpa enkripsi. Itu poin yang bagus. Selain itu saya tidak melihat apa pun yang membatasi Anda karena enkripsi restic.

Tidak mungkin kehilangan kunci enkripsi jika tidak dienkripsi. Itu sangat relevan untuk backup.

mebus

Tidak mungkin kehilangan kunci enkripsi jika tidak dienkripsi. Itu sangat relevan untuk backup.

Itu sudah dibahas seperti dunia akan berakhir besok :) https://github.com/restic/restic/issues/1786