Server incremental backup ke AWS Glacier


5

Saya mencari untuk membuat cadangan berbagai direktori dan file dari server Linux ke AWS Glacier. Saya mencoba mencari tahu detail cara mengelola ini.

Cadangan Tambahan

Saya ingin mengunggah file secara bertahap. Jadi intinya, jika file tidak berubah, saya tidak ingin mengunggahnya lagi ke Glacier jika sudah ada di sana. Saya pikir saya sudah tahu bagian ini. Karena Anda tidak bisa mendapatkan daftar instan arsip di lemari es Glacier Anda, saya akan menyimpan basis data lokal file yang diunggah, agar dapat mengetahui apa yang ada di dalam lemari besi dan apa yang tidak. Ini akan memungkinkan saya untuk melakukan backup tambahan (hanya mengunggah file yang hilang atau diubah).

Tidak Dapat Menimpa File?

Menurut ( http://aws.amazon.com/glacier/faqs/ ):

Arsip yang disimpan di Amazon Glacier tidak dapat diubah, yaitu arsip dapat diunggah dan dihapus tetapi tidak dapat diedit atau ditimpa.

Jadi apa yang terjadi jika saya mengunggah file / arsip, kemudian file berubah secara lokal, dan lain kali saya melakukan backup, bagaimana cara Glacier menangani hal ini karena tidak dapat menimpa file dengan versi baru?

Menghapus Data Lama

AWS mengenakan biaya $ 0,03 per GB untuk menghapus arsip yang berumur kurang dari 3 bulan. Karena saya sedang melakukan backup dari server lokal, saya ingin menghapus arsip yang sudah tidak ada secara lokal. Apa cara terbaik untuk mengatur ini. Gunakan inventaris arsip yang disimpan secara lokal untuk menentukan data apa yang tidak ada lagi dan jika> 3 bulan, hapus dari Glacier? Itu kelihatannya mudah tetapi apakah ada pendekatan yang lebih baik untuk ini?

File individual vs. file TAR / ZIP

Anda dapat mengunggah file individual sebagai arsip atau menjadi lebih efisien dengan mengelompokkan file Anda ke dalam file TAR atau ZIP sebelum mengunggah. Ide file TAR / ZIP menarik karena membuatnya lebih sederhana dan Anda dikenakan biaya penyimpanan yang lebih kecil, tapi saya ingin tahu bagaimana saya akan berurusan dengan unggahan tambahan. Jika file zip 20 MB diunggah yang berisi 10.000 file, dan salah satu file itu diubah secara lokal, apakah saya perlu mengunggah file zip 20 MB lainnya? Sekarang saya diharuskan untuk memakan biaya penyimpanan 2 salinan dari hampir semua hal dalam file zip itu ... Juga, bagaimana saya akan berurusan dengan menghapus hal-hal dalam file ZIP yang tidak ada secara lokal lagi? Karena saya tidak ingin menghapus seluruh file zip, sekarang saya dikenai biaya untuk menyimpan file yang tidak ada lagi.

Mungkin saya terlalu memikirkan semua ini. Apa cara paling mudah untuk mendekati pertanyaan-pertanyaan ini?

Saya tidak tahu apakah itu penting atau tidak, tapi saya menggunakan PHP SDK untuk skrip cadangan ini. Saya juga tidak ingin mengunggah ke ember S3 terlebih dahulu dan kemudian mencadangkan ember ke Glacier karena sekarang saya harus membayar biaya penyimpanan S3 dan biaya transfer juga.

Jawaban:


3

Jadi apa yang terjadi jika saya mengunggah file / arsip, kemudian file berubah secara lokal, dan lain kali saya melakukan backup, bagaimana cara Glacier menangani hal ini karena tidak dapat menimpa file dengan versi baru?

Per FAQ Gletser :

Anda menyimpan data di Amazon Glacier sebagai arsip. Setiap arsip diberi ID arsip unik yang nantinya dapat digunakan untuk mengambil data. Arsip dapat mewakili satu file atau Anda dapat memilih untuk menggabungkan beberapa file untuk diunggah sebagai arsip tunggal. Anda mengunggah arsip ke dalam brankas. Vault adalah koleksi arsip yang Anda gunakan untuk mengatur data Anda.

Jadi artinya ini adalah setiap file yang Anda unggah diberi ID unik. Unggah file yang sama dua kali dan setiap salinan file mendapatkan IDnya sendiri. Ini memberi Anda kemampuan untuk mengembalikan ke versi file sebelumnya jika diinginkan.

Gunakan inventaris arsip yang disimpan secara lokal untuk menentukan data apa yang tidak ada lagi dan jika> 3 bulan, hapus dari Glacier? Itu kelihatannya mudah tetapi apakah ada pendekatan yang lebih baik untuk ini?

Untuk menghindari biaya tambahan untuk menghapus data yang kurang dari 3 bulan, ini mungkin merupakan pendekatan terbaik. Tetapi itu bukan hanya data yang tidak ada lagi yang perlu Anda lacak & hapus. Seperti disebutkan di atas, setiap kali file berubah dan Anda mengunggahnya kembali ke Glacier, Anda akan mendapatkan ID baru untuk file tersebut. Anda pada akhirnya juga ingin menghapus versi file yang lebih lama, dengan asumsi Anda tidak ingin kemampuan untuk mengembalikan ke versi yang lebih lama.

Jika file zip 20 MB diunggah yang berisi 10.000 file, dan salah satu file itu diubah secara lokal, apakah saya perlu mengunggah file zip 20 MB lainnya? Sekarang saya diharuskan untuk memakan biaya penyimpanan 2 salinan dari hampir semua hal dalam file zip itu ... Juga, bagaimana saya akan berurusan dengan menghapus hal-hal dalam file ZIP yang tidak ada secara lokal lagi? Karena saya tidak ingin menghapus seluruh file zip, sekarang saya dikenai biaya untuk menyimpan file yang tidak ada lagi.

Itu adalah pengorbanan yang harus Anda putuskan sendiri. Apakah Anda tar / zip semuanya dan kemudian dipaksa untuk melacak file-file itu dan semua yang ada di dalamnya, atau apakah itu layak bagi Anda untuk mengunggah file secara individual sehingga Anda dapat membersihkannya secara individual karena mereka tidak lagi diperlukan.

Beberapa pendekatan lain yang mungkin Anda pertimbangkan:

  • Memiliki dua atau lebih arsip tar / zip, yang berisi file yang sangat tidak mungkin untuk diubah (seperti file sistem) dan lainnya yang berisi file konfigurasi dan hal-hal lain yang lebih mungkin berubah dari waktu ke waktu.
  • Jangan repot-repot melacak file individual dan mencadangkan semuanya dalam arsip tar / zip tunggal yang akan diunggah ke Glacier. Karena setiap arsip mencapai titik 3 bulan (atau bahkan mungkin lebih baru) hapus saja. Itu memberi Anda cara yang sangat mudah untuk melacak & memulihkan dari titik waktu tertentu.

Namun, setelah mengatakan semua itu, Gletser mungkin bukan pendekatan terbaik untuk kebutuhan Anda. Gletser benar-benar dimaksudkan untuk pengarsipan data, yang berbeda dari sekadar membuat cadangan server. Jika Anda hanya ingin melakukan backup server secara bertahap, maka gunakan S3 sebagai ganti dari Glacier mungkin merupakan pendekatan yang lebih baik. Menggunakan alat seperti Duplicity atau rdiff-backup (bersama dengan sesuatu seperti s3fs ) akan memberi Anda kemampuan untuk mengambil cadangan tambahan ke bucket S3 dan mengelolanya dengan sangat mudah. Saya telah menggunakan rdiff-backup pada beberapa sistem linux selama bertahun-tahun dan ternyata itu bekerja dengan cukup baik.


1

Berikut adalah alat baris perintah untuk * nix, yang mendukung pengunggahan file yang hanya dimodifikasi, mengganti file yang dimodifikasi secara lokal dan menghapus file yang dihapus secara lokal dari Glacier https://github.com/vsespb/mt-aws-glacier


0

Sebagai alternatif, Anda bisa menggunakan sesuatu seperti Duplicity , lalu unggah arsip yang dihasilkannya.

Ini memiliki beberapa manfaat:

  • Duplicity melakukan incremental backup, jadi hanya file yang diubah yang ditangkap dalam set cadangan
  • Duplicity dapat menangani perubahan file, jadi jika hanya sebagian kecil file diubah, secara teori, hanya perubahan yang diunggah
  • Cadangan Anda dienkripsi, jika Anda adalah tipe paranoid

Cara termudah untuk menggunakan Duplicity with Glacier adalah:

  • Cadangkan ke direktori lokal di suatu tempat (dan simpan cadangan ini). Duplicity memerlukan akses ke file "manifes" itu setiap kali cadangan dijalankan sehingga dapat mengetahui file mana yang telah berubah.
  • Unggah arsip baru yang dibuat oleh Duplicity ke Glacier dari cadangan lokal Anda. Gunakan sesuatu seperti gletser-cmd untuk ini.

Karena Anda tidak dapat mengindeks atau dengan mudah mengakses file Glacier bagaimana Duplicity akan tahu jika file telah berubah atau tidak?
Jake Wilson

Duplicity menggunakan file manifes untuk mengetahui kapan file telah berubah. Inilah sebabnya mengapa lebih mudah jika Anda menyimpan salinan cadangan lokal juga. Anda juga dapat menyimpan hanya file manifes lokal, jika Anda mau skrip dalam kompleksitas tambahan.
pdey
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.