Bagaimana Anda membuat cadangan server penyimpanan?


14

Saya melihat penerapan server penyimpanan yang sangat besar untuk digunakan sebagai NAS langsung untuk beberapa server lain (semua berbasis Linux).

Dengan sangat besar, maksud saya antara 4TB dan 20TB ruang yang dapat digunakan (meskipun tidak mungkin kita akan benar-benar membuatnya 20TB).

Server penyimpanan akan menjadi RAID 10 untuk keamanan dan kinerja data, tetapi kami masih membutuhkan solusi cadangan termasuk cadangan di luar lokasi.

Pertanyaan saya adalah: Bagaimana Anda membuat cadangan data sebanyak itu !?

Ini tidak seperti saya hanya bisa menghubungkan hard drive portabel dan mentransfer file. Saat ini kami tidak memiliki perangkat lain dengan ruang penyimpanan sebanyak ini.

Apakah saya perlu membuat anggaran untuk server penyimpanan kedua di luar situs atau apakah ada solusi yang lebih baik?


5
Saya akan meninggalkan komentar saya yang biasa-biasa saja tentang dukungan untuk offline. Saya menjadi sangat gugup tentang sistem cadangan yang "hidup dan online" sepanjang waktu. Jika seorang penyerang bisa mendapatkan sistem produksi dan cadangan Anda maka mereka dapat membuang cadangan Anda segera setelah mereka selesai menghancurkan sistem produksi Anda.
Evan Anderson

@ Evan Saya lebih suka keduanya, memulihkan dari tape bisa memakan waktu berjam-jam, tetapi memulihkan dari lokal, atau disk yang terhubung langsung bisa dilakukan dalam hitungan menit.
Tom O'Connor

@Tim O'Connor: D2D2T sangat bagus ketika Anda bisa mendapatkannya. Ingatlah bahwa memulihkan setiap item dari disk atau kaset bisa sangat cepat. Cadangan berbasis disk memiliki reputasi cepat untuk dipulihkan, tetapi kebanyakan orang berpikir "mengakses data langsung dari media B2D" tidak "mengembalikannya" ketika mereka mengatakan itu. Jika Anda harus mengembalikan beberapa TB data dari sistem cadangan berbasis disk ke, katakanlah, SAN pengganti setelah Anda terbakar dalam api, itu tidak akan menjadi "menit" untuk memiliki data yang disalin. Disk dan tape kelas atas, dalam hal kecepatan transfer data, sangat mirip.
Evan Anderson

Jawaban:


13

Ada banyak cara untuk menangani data sebesar itu. Banyak hal tergantung pada lingkungan Anda dan berapa banyak uang yang bersedia Anda keluarkan. Secara umum ada beberapa strategi 'ambil data dari server' secara keseluruhan:

  • Melalui Ethernet Seperti yang tertulis di kotak, data dialirkan ke Some Where Else untuk penanganan. 20TB akan membutuhkan waktu lama untuk menyalin lebih dari 1GbE, tetapi itu bisa dilakukan. Perangkat keras dapat membantu (seperti tautan 10GbE, atau dalam beberapa kasus, ikatan NIC).
  • Melalui subsistem Penyimpanan Jika Anda menggunakan Fibre Channel, kirimkan ke perangkat lain di jaringan FC. Jika Anda memiliki SAS, kirimkan ke perangkat yang terhubung dengan SAS. Umumnya lebih cepat dari Ethernet.
  • Kirim ke array disk lain Kirim ke gudang penyimpanan lain yang terhubung ke server yang sama.

Itulah tampilan 100km. Setelah Anda mulai memperbesar hal-hal menjadi jauh lebih terfragmentasi. Seperti yang telah disebutkan, LTO5 adalah teknologi pita spesifik yang dirancang untuk jenis beban kepadatan tinggi ini. Array penyimpanan identik lainnya adalah target yang baik, terutama jika Anda dapat menggunakan sesuatu seperti GlusterFS atau DRBD untuk mendapatkan data di sana. Juga, jika Anda memerlukan rotasi cadangan atau hanya kemampuan untuk tetap berjalan jika array gagal akan mempengaruhi apa yang Anda tempatkan.

Setelah Anda memilih metode tampilan 100km, masuk ke perangkat lunak akan menjadi tugas besar berikutnya. Faktor-faktor yang memengaruhi ini adalah apa yang dapat Anda instal pada server penyimpanan Anda di tempat pertama (jika itu adalah NetApp, itu satu hal, server Linux dengan banyak penyimpanan adalah hal yang sama sekali berbeda, seperti halnya server Windows dengan banyak penyimpanan) , perangkat keras apa yang Anda pilih (tidak semua paket cadangan FOSS menangani perpustakaan tape dengan baik, misalnya), dan jenis retensi cadangan yang Anda butuhkan.

Anda benar-benar perlu mencari tahu Pemulihan Bencana seperti apa yang Anda inginkan. Replikasi langsung sederhana lebih mudah, tetapi tidak memungkinkan Anda untuk memulihkan dari minggu lalu saja. Jika kemampuan untuk memulihkan dari minggu lalu penting bagi Anda, maka Anda perlu merancang untuk hal semacam itu. Secara hukum (di AS dan tempat lain), beberapa data perlu disimpan selama 7+ tahun.

Replikasi sederhana adalah yang paling mudah dilakukan. Inilah yang dirancang DRBD untuk dilakukan. Setelah salinan awal selesai, itu hanya mengirimkan perubahan. Faktor-faktor rumit di sini adalah lokalitas jaringan, jika larik ke-2 Anda tidak dekat dengan DRBD utama mungkin tidak layak. Anda akan membutuhkan server penyimpanan kedua dengan ruang penyimpanan setidaknya sebanyak yang pertama.


Tentang cadangan kaset ...

LTO5 dapat menampung 1.5TB data tanpa kompresi. Memberi makan monster-monster ini membutuhkan jaringan yang sangat cepat, baik itu Fibre Channel atau SAS 6Gb. Karena Anda perlu mencadangkan lebih dari 1.5TB dalam pukulan keras, Anda perlu memeriksa autoloader (berikut adalah contohnya: tautan , autoloader 1-drive 24-slot 1-drive dari HP). Dengan perangkat lunak yang mendukungnya, mereka akan menangani penggantian kaset tengah untuk Anda. Mereka hebat. Anda masih harus menarik kaset untuk dikirim ke luar situs, tapi itu pemandangan yang lebih baik daripada berkeliaran sepanjang malam untuk memuat kaset sendiri ketika cadangan memanggil mereka.

Jika tape memberi Anda ' legacy, ew ' heebiegeebies, Virtual Tape Library mungkin lebih mempercepat Anda (seperti yang ini dari Quantum: link ). Ini berpura-pura menjadi tape library ke perangkat lunak cadangan sementara sebenarnya menyimpan sesuatu ke disk dengan teknik de-duplikasi yang kuat (Anda harap). Yang lebih keren bahkan akan menyalin kaset virtual ke kaset nyata untuk Anda, jika Anda suka hal semacam itu, yang bisa sangat berguna untuk rotasi di luar situs.


Jika Anda tidak ingin mempermasalahkan bahkan dengan kaset virtual, tetapi masih ingin melakukan backup direct-to-disk, Anda akan memerlukan array penyimpanan berukuran cukup besar untuk menangani 20TB itu, ditambah betapapun banyaknya data perubahan bersih yang Anda inginkan untuk terus memegang. Paket cadangan yang berbeda menangani ini secara berbeda. Beberapa teknologi de-duplikasi benar-benar bagus, yang lain adalah kludges hacky. Saya pribadi tidak tahu keadaan paket perangkat lunak cadangan FOSS di area ini (saya pernah mendengar tentang Bacula), tetapi mungkin cukup. Banyak paket cadangan komersial memiliki agen lokal yang Anda instal di server yang akan didukung untuk meningkatkan throughput, yang memiliki banyak manfaat.


Terima kasih atas jawaban panjang dan pemikirannya. Anda telah memberi saya banyak hal untuk direnungkan :-p
Andrew Ensley

9

Jukebox Wajib-5? Anda akan membutuhkan antara tiga dan 15 kaset untuk mendukung susunan itu, yang bukan jumlah besar. Jukebox akan mengganti kaset untuk Anda, dan perangkat lunak cadangan yang baik (misalnya bacula) akan melacak file mana yang ada di pita mana.

Anda juga akan ingin mempertimbangkan waktu yang diperlukan untuk membuat cadangan sistem file yang besar, karena sangat mungkin FS akan berubah selama periode itu. Untuk hasil terbaik, sistem file yang mendukung snapshot akan sangat membantu, sehingga Anda dapat mengambil snapshot instan dan melakukan backup penuh atau tambahan terhadap itu, alih-alih terhadap sistem file langsung.


1
Saya tidak terbiasa dengan sistem rekaman. Saya kira tidak ada cara untuk melakukan backup inkremental. Juga, bukankah akan memakan waktu beberapa jam dan melibatkan secara manual mengganti tape drive satu demi satu? Itu tidak akan ideal karena saya hanya akan memiliki waktu seperti itu sebulan sekali, dan kami benar-benar tidak ingin memiliki data berisiko sebulan. Apakah saya kehilangan sesuatu, atau ini hanya ketidaknyamanan / risiko / batasan dari sistem cadangan tape yang diterima?
Andrew Ensley

4
Sistem backup tape modern sangat otomatis dan robotik :)
phoebus

3
Ya, backup tape biasanya memungkinkan untuk incremental backup. Strategi pencadangan yang baik adalah melakukan pencadangan penuh (panjang, lambat, banyak kaset) bulanan atau dua kali setahun, dan lakukan pencadangan harian atau pencadangan diferensial di antaranya.
Brent

Robot tape harganya terjangkau dan menyimpan banyak kaset. Sejauh melakukan backup, mengapa tidak ada cara untuk melakukan incrementals? Akhirnya, sebagian besar orang memicu pencadangan agar beroperasi pada jam-jam libur. Jika Anda tidak memilikinya, itu bagian penting dari spesifikasi.
Slartibartfast

Ya, kami benar-benar tidak punya jam libur. Kami memiliki waktu berjam-jam agar sistem tidak tersedia (seperti jam 4 pagi hari Sabtu), tetapi sistem yang terpengaruh akan digunakan 24/7 oleh ratusan pengguna yang berpotensi.
Andrew Ensley

5

Anda mungkin harus melihat mencadangkan ke disk , karena rekaman akan memakan waktu lama, dan menjadi akses berurutan, mengembalikan akan memakan waktu lama.

Pasti memanfaatkan cadangan diferensial atau tambahan - hanya mencadangkan perubahan, pada frekuensi apa pun yang masuk akal bagi Anda.

Mungkin solusi ideal akan memiliki server berukuran 2 yang serupa di lokasi lain , di mana cadangan tambahan dikirim secara teratur, dan itu dapat ditukar dengan cepat jika server utama pernah mati. Namun opsi lain adalah menggunakan drive yang dapat dilepas di lokasi, yang kemudian dibawa ke luar kantor untuk penyimpanan.

Saat Anda berurusan dengan data sebanyak itu, masuk akal untuk memecah cadangan Anda menjadi pekerjaan cadangan yang lebih kecil, dan jika semuanya tidak dapat dicadangkan setiap hari, goyangkan cadangan Anda sehingga atur A akan dicadangkan satu hari, dan atur B berikutnya.

Selalu berpikir tentang prosedur pemulihan . Kami tersengat sekali ketika kami harus mengembalikan file dari pekerjaan cadangan beberapa ratus-manggung, yang membutuhkan banyak memori dan banyak waktu untuk membangun kembali indeks cadangan dan memulihkan. Pada akhirnya kami tidak dapat menyelesaikannya dalam sehari, dan harus membangun server pemulihan khusus untuk memungkinkan server cadangan utama kami melanjutkan pekerjaan malam hari!

--added--

Anda juga ingin memikirkan teknologi deduplikasi , yang dapat menghemat banyak ruang dengan tidak mencadangkan informasi yang sama beberapa kali, untuk banyak pengguna. Banyak solusi cadangan atau sistem file menawarkan deduplikasi sebagai bagian dari fungsionalitasnya.


+1 untuk thinking about the restore procedure. Amin!
Steven Senin

Banyak tips bagus. Terima kasih. Saya memiliki banyak pemikiran untuk dilakukan.
Andrew Ensley

2
Saya ingin meneguhkan hati, tetapi saya tidak melihat kaset yang disebutkan. Tape, sangat mungkin, akan menjadi bagian penting dari rezim cadangan untuk jumlah data tersebut jika diperlukan jendela retensi yang signifikan dikombinasikan dengan penyimpanan di luar lokasi. Biaya kartrid KPP-5 untuk penyimpanan off-site jangka panjang, dibandingkan dengan drive hard disk yang dapat dilepas, membuatnya sangat menarik. Kartrid pita juga dirancang untuk penyimpanan arsip sedangkan drive hard disk yang dapat dilepas biasanya tidak.
Evan Anderson

@ Evan: Agar adil, dia menyebutkan kaset dalam kalimat pertama.
Andrew Ensley

2

Pertama, sebutkan risiko yang Anda lindungi. Beberapa risiko umum:

  • Bencana: Sesuatu yang sangat disayangkan terjadi pada seluruh situs Anda.
  • Kesalahan manusia (inilah yang terjadi _all_the_time_):
    • Seseorang memutuskan untuk menggunakan kapabilitas "hot-swap" server penyimpanan Anda dengan cara yang tidak dimaksudkan oleh pabrikan.
    • Seseorang menjalankan proses yang secara diam-diam merusak data, yang dicadangkan dengan andal selama beberapa bulan sebelum masalahnya diketahui.
    • Seseorang menghapus laporan penting yang jatuh tempo dalam satu jam dan bernilai ribuan dolar.

Kemudian evaluasi biaya berbagai solusi penghindaran risiko, misalnya:

  • Pencadangan di luar lokasi, on-line (cermin jarak jauh): Aman dari bencana, sebagian (tetapi tidak semua) kesalahan manusia (masih on-line).
  • Penyimpanan off-line off-site (kaset): Aman dari bencana, sulit memulihkan data dengan cepat.
  • Pencadangan online (mirror) di tempat: Aman dari kesalahan manusia, kegagalan perangkat keras, rentan terhadap bencana.
  • Cadangan off-line di tempat (kaset di tape changer): Aman dari sebagian besar kesalahan manusia, sebagian besar kegagalan perangkat keras.

Kemudian evaluasi strategi rotasi (seberapa jauh Anda ingin dapat pulih, berapa banyak data yang Anda bisa kehilangan).

Kemudian pilih nilai data Anda.


Terobosan bagus. Saya sudah mengevaluasi ini untuk sebagian besar dan mendarat di Off-site, opsi cadangan online. Tujuan cadangan sebagian besar untuk melindungi dari bencana selain kesalahan manusia yang jelas. Rak ini terletak dalam jarak 2 mil dari pantai teluk, jadi angin topan menjadi perhatian. Kami hanya harus melakukan yang terbaik untuk melindungi dari kesalahan manusia dengan pemeriksaan integritas yang sering. Jawaban Anda membantu saya merasa lebih baik tentang kesimpulan ini. Terima kasih.
Andrew Ensley

Aku senang bisa membantu. Beberapa komentar mengenai solusi yang Anda pilih: Ini bisa dikatakan, tetapi situs cadangan mungkin berada di negara bagian lain atau di tempat yang terlindungi dengan baik dari angin topan yang Anda alami. Anda dapat mengurangi masalah korupsi dengan memiliki 'ekor' panjang (cadangan dari berbagai tanggal di masa lalu). Dengan cadangan online, Anda juga ingin mempertimbangkan bahaya tidak sengaja menghapus data alih-alih mengembalikannya. Terakhir, selalu uji proses pemulihan Anda.
Slartibartfast

2

Saya memiliki pelanggan dengan dua sistem 12 TB serupa di dua gedung yang berbeda, terhubung pada 1GB. Salah satunya adalah sistem produksi; itu didukung secara bertahap (dengan snapshot harian) ke yang lain dengan utilitas rdiff-backup yang hebat. rdiff-backup harus tersedia di repositori distribusi standar Anda.


1

Pencadangan online, remote (cermin jarak jauh)

gunakan rsync meskipun ssh (hanya perubahan) - backup pertama harus dilakukan secara lokal, tetapi setelah itu backup akan sangat mudah tergantung pada perubahan

jika Anda perlu menyimpan versi dengan perubahan-rdiff-backup

http://www.nongnu.org/rdiff-backup/

sistem file btrfs di Linux terdengar menjanjikan, tetapi masih dalam pengembangan


Terima kasih telah mengarahkan saya ke rdiff. Saya sudah menggunakan rsync, dan ini sepertinya langkah yang sempurna untuk itu.
Andrew Ensley

1

Lihatlah "konten" Anda yang sebenarnya dan seberapa sering itu berubah sebelum Anda merencanakan strategi Anda. Banyak kali orang hanya membuat data yang sama untuk direkam setiap minggu berulang kali tanpa alasan yang jelas.

Teknologi deduplikasi dari beberapa vendor dapat memungkinkan snapshotting untuk menyelamatkan Anda dari pemulihan file individual, tetapi Anda akan selalu membutuhkan di luar kantor untuk perlindungan.


Sistem ini akan digunakan oleh ribuan kemungkinan puluhan ribu pengguna harian memasukkan formulir dan memperbarui informasi. Ini adalah data yang sangat dinamis. Saya seharusnya menyebutkan itu dalam pertanyaan.
Andrew Ensley

Jika itu saya, saya akan merancang sistem dengan overhead atau kemampuan snapshot yang cukup sehingga saya tidak perlu pergi ke backup nyata kecuali jika itu adalah bencana.
SpacemanSpiff

Saya setuju. Seperti yang saya katakan sebelumnya, drive akan berada di RAID 10, jadi kami dilindungi jika terjadi kegagalan hard drive, dan saya akan memiliki cadangan / snapshot lokal juga. Pencadangan di luar kantor adalah untuk skenario terburuk seperti meteor yang mengenai lokasi bersama atau seseorang yang secara tidak sengaja menjalankan rm -rf / * di server penyimpanan.
Andrew Ensley

Yah, saya mengacu pada overhead dalam hal kapasitas. RAID10 cerdas untuk redundansi terbaik tentu saja, tapi saya akan mengambil RAID6 jika kinerja tidak sebanyak persyaratan dan jika saya bisa menggunakan ruang ekstra untuk area snapshot lebih banyak. Semakin banyak snapshot yang Anda mampu, semakin sedikit Anda akan membutuhkan "cadangan" untuk mengembalikan file.
SpacemanSpiff
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.