cadangan terenkripsi untuk Linux dan FreeBSD dapat dibaca untuk keduanya


8

Saya memiliki komputer Linux dan FreeBSD, keduanya dienkripsi (masing-masing LUKS dan geli). Saya bertanya-tanya bagaimana cara membuat cadangan yang juga akan dienkripsi dan dapat dibaca oleh keduanya (sehingga jika salah satu komputer gagal saya dapat dengan cepat memulihkan data menggunakan yang lain).

Sayangnya sepertinya bot LUKS dan geli adalah modul kernel untuk sistem masing-masing yang belum pernah diporting ke yang lainnya. Dilihat dari beberapa ancaman pada sistem file yang kompatibel dengan BSD / Linux, tampaknya cukup sulit untuk membuat cadangan yang tidak terenkripsi yang dapat dibaca oleh keduanya (ext2 tampaknya menjadi satu-satunya pilihan untuk sistem file yang memungkinkan ini).

Jadi pikiran saya adalah untuk membuat FreeBSD virtual di KVM Linux yang akan dapat membaca dan menulis disk eksternal terenkripsi geli dan mentransfer data ke volume ext2 virtual yang tidak terenkripsi di dalam sistem file terenkripsi LUKS Linux (dan sebaliknya) sekitar). Namun, ini tampaknya sangat rumit dan tidak benar-benar terasa seperti cara yang tepat untuk melakukannya.

Apakah ada cara yang lebih baik / lebih mudah / lebih disukai? Atau apakah cara yang dijelaskan di atas saat ini merupakan opsi terbaik?

Terima kasih; Saya menghargai setiap pemikiran tentang masalah ini.


2
Satu-satunya pemikiran yang saya lihat dalam daftar ini adalah en.wikipedia.org/wiki/… yang didukung pada keduanya adalah eCryptFS en.wikipedia.org/wiki/ECryptfs. Namun itu bukan enkripsi tingkat blok. Ini adalah lapisan sistem file.
Zoredache

1
Saya akan lebih cepat mengatur kotak lain dengan OS favorit saya untuk melayani dan menyimpan cadangan.
Ярослав Рахматуллин

Terima kasih banyak untuk Anda berdua. Saya berharap suatu saat di masa depan seseorang akan port LUKS ke FreeBSD atau geli ke Linux (sayangnya saya kurang memiliki keterampilan / pengalaman pemrograman yang diperlukan dan waktu untuk mendapatkannya.)
0range

Jawaban:


3

Mari kita buat beberapa asumsi. Berikan komentar jika itu tidak benar.

  1. Anda menjalankan mesin dengan sistem operasi yang berbeda, dan platform yang berpotensi berbeda.
  2. Anda menggambarkannya untuk kasus dengan 2 mesin, dan Linux dan FreeBSD
  3. mesin Anda menggunakan sistem file terenkripsi
  4. Anda ingin membuat cadangan data Anda, dan ingin cadangan itu juga dienkripsi
  5. Anda ingin dapat mengakses data dalam cadangan terenkripsi dari salah satu platform yang berkontribusi pada arsip

(komentar ditambahkan untuk membuat perbedaan antara bentuk enkripsi)

Anda menyebutkan bahwa Anda ingin dapat mengakses data sistem lain, dari mesin yang selamat. Salah satu caranya adalah dengan menyimpan cadangan yang tidak dienkripsi, pada mesin lokal, pada sistem file yang dienkripsi. Yang lain bisa menyimpan cadangan terenkripsi, pada mesin lokal, pada sistem file yang tidak terenkripsi. Saya sarankan untuk menyimpan cadangan terenkripsi, pada sistem file yang tidak terenkripsi.

Namun, sebagai tambahan - selalu ada kekhawatiran tentang cadangan terenkripsi: - Anda benar-benar harus berhati-hati dengan kunci - korupsi parsial biasanya membunuh seluruh cadangan

saran saya: gunakan

untuk membuat cadangan ke satu atau beberapa kontainer yang dapat diakses oleh kedua mesin.

Untuk menyimpan semuanya di dalam LAN Anda, Anda dapat:

  1. buat sistem file "cadangan" di kedua host, untuk menyimpan "paket" cadangan yang dienkripsi. Tidak perlu filesystem terenkripsi, karena cadangan "paket" (brackup menyebutnya "potongan") yang tersimpan di dalamnya akan dienkripsi
  2. ekspor sistem file ini, misalnya dengan NFS, dan pasang masing-masing di host lain
  3. ketika Anda membuat cadangan, membuangnya ke sistem file lokal, dan mirror mereka ke direktori yang dipasang NFS di host lain. Ini memiliki efek samping yang bagus karena memiliki dua contoh file cadangan Anda.

Anda sekarang akan memiliki sistem file berikut di server Anda:

on tux, mesin Linux Anda:

/dev/foo            /           # encrypted filesystem
/dev/bar            /tuxdump    # unencrypted filesystem, local backup
beastie:/daemondump /daemondump # NFS backup destination

pada beastie, Anda mesin FreeBSD:

/dev/flurb          /           # encrypted filesystem
/dev/baz            /daemondump # unencrypted filesystem, local backup
tux:/tuxdump        /tuxdump    # NFS backup destination

tergantung pada jumlah data yang Anda butuhkan untuk membuat cadangan, Anda juga bisa memikirkan wadah di luar kantor, penyedia cloud mana pun akan melakukannya. Saat ini saya bermain-main dengan mengkonfigurasi wadah S3 saya sehingga barang-barang lama menjadi tua untuk Glacier, yang terlihat sangat menjanjikan, mengingat harga.


tidak persis. saya tidak perlu menjadi blok-demi-blok dan saya tidak perlu melewati jaringan (meskipun alat yang Anda sarankan tampak sangat menarik). masalahnya agak (seperti yang telah dipahami dengan benar oleh Zoredache dan Ярослав Рахматуллин) bahwa jika salah satu sistem rusak karena suatu alasan saya perlu cara untuk mengakses cadangan. sehingga cadangan harus disimpan pada sistem file terenkripsi (pada disk lain) yang dapat diakses oleh kedua sistem. ini menimbulkan masalah karena sistem enkripsi asli dan filesystem asli dari linux dan freebsd tidak kompatibel. maaf tidak merespons sebelumnya.
0range

oh, dan saya harus menyebutkan bahwa beberapa tarbal terenkripsi secara manual untuk saya sebagai penerima PGP saya. Pengaturan yang lebih cerdas nantinya memiliki dua file, satu arsip dienkripsi dengan kunci simetris, dan kunci dienkripsi dengan PGP, keduanya di tarball lain, sehingga file tidak hilang pada saat transfer. Tidak ada yang sebagus script yang disebutkan, tetapi berhasil.
Florenz Kley

Saya belum pernah mendengar tentang kepalsuan, tetapi sepertinya persis seperti apa yang saya cari! Apakah Anda tahu berapa umurnya? Apakah stabil? Saya tidak dapat menemukan tanggal kapan proyek dimulai.
cnst

Duplicity [ dupity.nongnu.org] telah ada sejak 2002, saya menggunakannya sejak ca. 2004.
Florenz Kley

@ 0range - membersihkan sedikit perbedaan "enkripsi". Yang saya usulkan bukan blok demi blok, ini berbasis file. Sarankan untuk menggunakan sistem file yang tidak terenkripsi, karena mereka dapat dibaca oleh kedua sistem. Menyimpan cadangan terenkripsi pada mereka, mereka juga dapat dibaca di kedua platform oleh masing-masing alat asli. Itu harus mencentang kotak di kedua persyaratan Anda, enkripsi dan keterbacaan, pada kedua platform.
Florenz Kley

2

Duplicity - alat yang hebat untuk tugas ini, menggunakan GPG untuk enkripsi. Saya menggunakannya untuk beberapa waktu dan saya sangat merekomendasikan.

Sebagai alternatif, Anda dapat mencoba:

  • obnam - adalah proyek baru, tetapi memiliki beberapa fitur bagus (agak lambat jika menggunakan ssh / scp)
  • bersendawa - enkripsi dengan kata sandi

lihat komentar saya untuk jawaban Florenz Kley di atas. (dan terima kasih telah menyarankan alat-alat itu)
0range

Maaf, saya hanya bisa menambahkan komentar di sini. Alat-alat ini bukan blok-demi-blok, tetapi FS (Anda dapat membuat cadangan FS dan mengembalikannya bahkan di windows). GPG adalah standar untuk enkripsi - ini juga berfungsi pada keduanya. Program-program ini bukan hanya jaringan, Anda dapat cadangan dir ke dir. Jadi, dengan duplikat Anda dapat membuat cadangan kedua mesin dan mengembalikan cadangan terenkripsi di mana pun Anda memiliki duplikat dan kunci GPG.
spinus

2

TrueCrypt harus bekerja di Linux dan FreeBSD. Meskipun saya secara teratur menggunakan TrueCrypt hanya di bawah Windows dan belum mencoba FreeBSD Truecrypt sendiri. YMMV.


1

Anda dapat membuat cadangan file mesin Anda menggunakan biasa rsyncdi hard drive komputer lain. Ketika Anda menggunakan enkripsi lokal, itu dienkripsi dengan enkripsi sistem lokal dan transmisi diamankan oleh TLS. Pembaruan cepat dan Anda tetap dengan enkripsi dan mekanisme cadangan yang terbukti dengan baik.

Jika Anda hanya perlu membuat cadangan file pada beberapa sistem yang tidak dipercaya, GPG biasa bekerja dengan baik untuk saya. Saya mengotomatiskan beberapa enkripsi dan transfer FTP dengan python, yang sudah berjalan dengan baik selama dua tahun.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.