Cara memilih layanan cloud untuk cadangan

12

Saya berpikir untuk menggunakan layanan cloud untuk mencadangkan salah satu situs web klien saya.

Kekhawatiran utama (klien) saya adalah (dalam mengurangi urutan kepentingan)

  1. Perlindungan IP (rahasia dagang, kode sumber), detail akun pengguna, dll
  2. Jaminan uptime yang ditawarkan oleh penyedia layanan (untuk meminimalkan waktu server turun)
  3. Biaya
  4. Kecepatan unggah / unduh

Idealnya, saya ingin layanan yang tidak memiliki ikatan panjang (yaitu saya lebih suka jenis layanan "bayar saat Anda bepergian")

Saya juga ingin menghindari loket vendor, di mana hampir tidak mungkin untuk pindah ke layanan lain.

Saya ingin beberapa pedoman umum tentang:

  1. Bagaimana cara memilih penyedia layanan
  2. Siapa pemain utama di lapangan
  3. rekomendasi perangkat lunak yang akan digunakan untuk: membuat cadangan / memulihkan / dan mengunggah / mengunduh file yang disimpan / dipulihkan

Perangkat lunak servernya adalah Ubuntu atau Debian (saya mungkin akan mengirim pertanyaan tentang OS mana yang akan digunakan sebagai server - Saya sudah terbiasa dengan Ubuntu)

RichVel
sumber
Seberapa besar situs webnya? Apakah ini termasuk basis data besar? Adakah angka ball-park tentang seberapa banyak yang bersedia dibelanjakan klien? ($ 100 / bulan, $ 10.000 / bulan?)
RJFalconer
3
sejauh menyangkut "rahasia dagang dan kode sumber", informasi yang sangat penting tidak termasuk ke dalam "cloud", terlepas dari seberapa pun reputasi sebuah layanan.

Jawaban:

4

Solusi apa pun yang tidak termasuk enkripsi pada sisi klien dengan kunci yang dipegang oleh pemilik tidak akan memenuhi persyaratan yang dinyatakan pertama (perlindungan / keamanan IP) - setiap retasan dari sisi server mengungkapkan data yang tidak terenkripsi. Ini mengesampingkan sistem sinkronisasi cloud seperti Dropbox yang memiliki kunci.

Untuk menghindari hosting kunci enkripsi yang sangat penting di server situs web, yang juga kemungkinan akan diretas di beberapa titik, inilah yang akan saya lakukan:

  1. Server cadangan internal di situs milik pelanggan - memiliki kunci enkripsi dan kunci SSH untuk kedua server lainnya
  2. Server hosting situs web - bisa menjadi host web
  3. Server atau layanan cadangan cloud

Langkah 1: Server (1) menarik cadangan dari (2), sehingga sebagian besar peretasan server situs web tidak akan mengganggu cadangan. Enkripsi terjadi pada titik ini.

  • Saya akan menggunakan rsnapshot melalui SSH menggunakan login berbasis kunci, karena ini memiliki persyaratan minimal pada host web dan server cadangan internal - kecuali Anda memiliki DB besar untuk mencadangkannya, ini sangat efisien dalam bandwidth dan menyimpan beberapa versi situs, dan juga menangani pembersihan cadangan lama.
  • Enkripsi dapat dilakukan oleh file apa saja untuk alat file seperti GPG, menyalin pohon rsnapshot ke pohon lain - atau Anda dapat menggunakan duplikat untuk langkah 2, menghemat ruang disk.
  • "Tarik" dari server cadangan penting - jika server utama (2) memiliki kata sandi / kunci untuk server cadangan, peretas dapat dan terkadang akan menghapus cadangan setelah meretas server utama (lihat di bawah). Peretasan yang benar-benar canggih dapat menginstal binari SSH trojan yang kemudian dapat membahayakan server cadangan, tetapi itu lebih kecil kemungkinannya bagi kebanyakan perusahaan.

Langkah 2: server (1) mendorong cadangan terenkripsi ke (3) sehingga ada cadangan di luar kantor. Jika cadangan dienkripsi di langkah 1, Anda bisa menggunakan mirror rsync dari pohon rsnapshot lokal ke sistem jarak jauh.

  • Duplicity akan menjadi pilihan yang baik untuk secara langsung mengenkripsi dan membuat cadangan pohon rsnapshot yang tidak terenkripsi ke server jarak jauh. Bermuka dua ini fitur yang sedikit berbeda untuk rsnapshot, menggunakan arsip tar GPG-dienkripsi, tetapi memberikan enkripsi cadangan pada remote host dan hanya membutuhkan SSH pada host itu (atau bisa menggunakan Amazon S3). Duplikasi tidak mendukung tautan keras , jadi jika ini diperlukan (misalnya untuk cadangan server penuh), yang terbaik adalah jika skrip mengubah pohon rsnapshot (yang mendukung tautan keras) menjadi file tar (mungkin hanya file yang memiliki> 1 hard link, yang akan sangat kecil) sehingga duplikat dapat membuat cadangan file tar.
  • Karena server jarak jauh hanyalah host SSH, mungkin dengan rsync, itu bisa berupa host web (tetapi dari penyedia hosting yang berbeda dan di bagian negara yang berbeda), atau layanan cloud yang menyediakan rsync dan / atau SSH - lihat jawaban ini pada backup rsync ke cloud untuk rekomendasi bqbackup dan rsync.net, meskipun saya tidak setuju dengan pengaturan backup yang disebutkan.
  • Anda dapat menggunakan Amazon S3 sebagai server jarak jauh dengan duplikat, yang akan memberi Anda ketersediaan yang sangat baik meskipun mungkin akan lebih mahal untuk cadangan besar.
  • Pilihan lain untuk backup terenkripsi jarak jauh adalah Boxbackup (tidak cukup matang, beberapa fitur bagus) dan Tarsnap (layanan cloud komersial berdasarkan Amazon S3 dengan antarmuka baris perintah sederhana, deduplikasi yang baik, dan enkripsi yang sangat teliti).

Keamanan dari semua berbagai host adalah penting, jadi ini harus disesuaikan untuk memenuhi profil keamanan klien yaitu menganalisis ancaman, risiko, vektor serangan, dll. Server Ubuntu bukan awal yang buruk karena telah sering memperbarui keamanan untuk 5 tahun, tetapi perhatian terhadap keamanan diperlukan di semua server.

Pengaturan ini menyediakan 2 cadangan independen, salah satunya dapat menjadi layanan penyimpanan cloud yang sangat tersedia, beroperasi dalam mode tarik sehingga sebagian besar serangan pada situs web tidak dapat menghancurkan cadangan pada saat yang sama, dan menggunakan alat sumber terbuka yang terbukti baik yang tidak memerlukan banyak administrasi.

  • Pencadangan independen sangat penting, karena peretas terkadang benar-benar menghapus semua cadangan pada saat yang sama dengan peretasan situs web - dalam kasus terbaru peretas menghancurkan 4800 situs web, termasuk cadangan dengan meretas lingkungan web hosting daripada situs. Lihat juga jawaban ini dan yang ini .
  • Memulihkan sangat mudah dengan rsnapshot - ada satu file di setiap pohon snapshot untuk setiap file yang dicadangkan, jadi temukan saja file dengan alat Linux dan rsync atau scp kembali ke situs web. Jika server cadangan di tempat tidak tersedia karena alasan tertentu, cukup gunakan duplikat untuk memulihkannya dari server cadangan cloud - atau Anda dapat menggunakan alat standar seperti GPG, rdiff, dan tar untuk mengembalikan cadangan.

Karena pengaturan ini menggunakan SSH dan rsync standar, akan lebih mudah untuk memilih penyedia yang sesuai dengan jaminan uptime yang tepat, keamanan yang kuat, dll. Anda tidak harus mengunci kontrak yang panjang, dan jika layanan cadangan memiliki bencana besar kegagalan, Anda masih memiliki cadangan lokal dan dapat dengan mudah beralih ke layanan cadangan lain.

RichVel
sumber
rsnapshot tidak hanya mendukung hardlink, tetapi juga menggunakannya dalam representasi internal. Jadi duplikat tidak akan mencadangkan penyimpanan data rsnapshot dengan benar tanpa menaruhnya.
ptman
@ptman: Itu benar - namun tidak semua pohon rsnapshot perlu ditumpuk. Saya akan menggunakan duplikat untuk membuat cadangan direktori rsnapshot "daily.0" hanya di pohon rsnapshot, yang memiliki snapshot terbaru dari pohon direktori yang didukung. Tautan antar-snapshot Rsnapshot antara daily.0, daily.1, dll, tidak relevan dengan cadangan duplikat, yang hanya melihat tautan antara dua file di dalam pohon snapshot daily.0, yang terkait dengan tautan keras pada sistem yang didukung. Tar dapat menangkap tautan itu OK dan duplikat dapat mencadangkannya melalui file tar.
RichVel
2

Dari segi perangkat lunak, pertimbangkan duplikasi untuk cadangan tambahan dengan enkripsi asimetris dan penerima bisu ( howto non-cloud ).

Tobu
sumber
1

Saya selalu memberi tahu klien saya bahwa solusi cadangan terbaik, paling murah dan paling efisien adalah solusi yang Anda buat sendiri, untuk keperluan Anda sendiri.

Ketika saya membangun sistem untuk klien saya, saya menggunakan rsync dengan kunci SSH untuk menangani otentikasi antara serverA dan serverB, di mana serverA berisi data yang akan didukung. Perintah untuk mengarsipkan dan me-rsync data terkandung dalam skrip bash di direktori yang tidak dapat diakses web, dipanggil oleh cron setiap jam H (24 untuk harian, dll.)

Server cadangan, serverB, harus digunakan SEGERA untuk cadangan. Saya selalu menyarankan klien saya untuk menggunakan kata sandi yang sangat panjang dengan otentikasi kunci SSH untuk memungkinkan pengunduhan cadangan dan pencadangan. Terkadang, klien saya perlu cadangan untuk disimpan selama D hari, jadi saya menulis beberapa skrip untuk mengatasinya (mengambil data dari direktori cadangan aktif, menerapkan stempel waktu, tambahkan ke arsip di direktori lain).

Jason Berlinsky
sumber
0

Untuk usaha kecil / prosumer, saya akan merekomendasikan Layanan Penyimpanan Amazon .

  • Kontrol wilayah (Yaitu objek yang disimpan di UE tidak pernah meninggalkan UE).
  • Uptime 99,9% untuk setiap siklus penagihan yang diberikan
  • $ 0,150 per GB disimpan per bulan
  • $ 0,170 per GB diunduh
  • Unggah gratis hingga Juni 2010, $ 0,10 per GB sesudahnya

Dan jaminan yang agak kabur bahwa "Mekanisme otentikasi disediakan untuk memastikan bahwa data tetap aman dari akses yang tidak sah"

RJFalconer
sumber
0

Meskipun bluenovember berada di jalur yang benar dengan S3, sistem Amazon sebenarnya bukan solusi cadangan drop-in, ini adalah solusi penyimpanan data mentah yang masih memerlukan sistem ujung depan yang akan digunakan untuk cadangan, baik itu panggilan API atau suite manajemen cadangan lengkap. Sesuatu seperti JungleDisk Server Edition , yang menggunakan S3 di backend tetapi menyediakan antarmuka yang lebih baik untuk digunakan sebagai solusi cadangan, mungkin akan lebih baik.

Selain itu, JungleDisk akan memberi Anda enkripsi bawaan, sesuatu yang perlu Anda tambahkan terlepas dari bagaimana Anda berencana untuk terhubung ke S3 / "cloud". Mereka memiliki beberapa softwre klien yang cukup bagus untuk Linux juga.

matahari
sumber
0

Saya suka menyimpan cadangan saya di Amazon AWS dan saya menggunakan alat gratis s3cmd ( http://s3tools.org/s3cmd )

Ini dapat diinstal dengan mudah (Debian: apt-get install s3cmd).

Yang Anda butuhkan adalah akun Amazon AWS untuk menyimpan file Anda di S3. Kemudian perintah sederhana dapat menjalankan cadangan Anda, bahkan secara bertahap atau sebagai solusi sinkronisasi, misalnya:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

Pastikan Anda berlari

s3cms --configure 

pertama yang memasukkan kredensial AWS Anda.

rampok
sumber