Apakah snapshots + RAID dianggap sebagai solusi cadangan yang baik di tempat?

Dua alasan utama yang dapat saya pikirkan untuk mengambil cadangan tampaknya diatasi ketika saya menggunakan snapshot dan RAID bersama dengan btrfs. (Dengan RAID di sini, maksud saya RAID1 atau 10)

• Penghapusan data secara tidak disengaja: Snapshots mencakup kasus ini
• Kegagalan drive dan bit busuk
  • Kegagalan total: RAID mencakup kasus ini
  • Drive mengembalikan data buruk: Fitur koreksi kesalahan RAID + btrfs mencakup kasus ini

Jadi sebagai solusi cadangan di tempat, ini tampaknya berfungsi dengan baik, dan bahkan tidak memerlukan perangkat penyimpanan data terpisah untuk itu!

Namun, saya telah mendengar bahwa baik RAID maupun snapshots tidak dianggap sebagai cadangan yang tepat, jadi saya ingin tahu apakah saya melewatkan sesuatu.

Selain btrf belum menjadi teknologi yang matang, bisakah Anda memikirkan sesuatu yang saya lewatkan? Atau apakah pemikiran saya benar dan ini adalah solusi cadangan di tempat yang valid?

Tidak, tidak.

Apa yang terjadi ketika sistem file atau volume RAID Anda rusak? Atau server Anda terbakar? Atau seseorang secara tidak sengaja memformat array yang salah?

Anda kehilangan semua data dan cadangan tidak nyata yang Anda pikir sudah Anda miliki. Itulah sebabnya cadangan nyata ada di sistem yang sama sekali berbeda dengan data yang Anda cadangkan - karena cadangan melindungi terhadap sesuatu yang terjadi pada sistem yang dipertanyakan yang akan menyebabkan kehilangan data. Simpan cadangan Anda di sistem yang sama saat Anda membuat cadangan, dan kehilangan data di sistem itu juga dapat memengaruhi "cadangan" Anda.

Untuk cadangan di tempat , snapshot mungkin cukup baik, asalkan Anda secara teratur 'mengekspor' snapshot Anda di tempat lain, di mana snapshot ada sebagai data pasif.

Dan, uji secara teratur apakah 'foto yang dikirim' Anda dapat dipulihkan.

Ini adalah bagaimana saya mengimplementasikan cadangan cepat dari beberapa server saya: menyimpan data pada ZFS, mengambil snapshot ZFS, mengirim delta ke server lain, di mana seluruh sistem file dibuat kembali (minus layanan aktual berjalan).

Tentu saja, cadangan terbaik selalu di luar situs. Jadi, setelah 'mengirimkan' foto-foto itu ke sistem yang terpisah, lakukan 'rekaman-' foto-foto itu secara teratur.

Jadi, dalam sistem saya, server yang menerima delta snapshot, secara teratur membuang semua kumpulan ZFS-nya (termasuk foto-foto sebelumnya) ke tape.

Dan tentu saja, uji kaset Anda untuk memastikannya dapat dikembalikan.

Catatan: Anda ingin snapshot berlangsung selama aktivitas disk yang diam, dan lebih disukai berkoordinasi dengan database (jika ada) untuk memastikan konsistensi; selain itu, obatnya mungkin lebih buruk daripada penyakitnya. Itu sebabnya fitur 'live snapshot' NetApp & EMC sangat berguna: Mereka akan menunda snapshot LUN sampai database menggunakan LUN menunjukkan bahwa aman untuk melakukan snapshot.

Apa yang dikatakan HopelessN00b. Tidak.

Cadangan yang tepat berada di perangkat terpisah dari perangkat yang dicadangkan. Apa yang terjadi ketika Anda kehilangan dua drive atau lebih? Apa yang terjadi ketika ruang server Anda terbakar? Apa yang terjadi ketika seseorang secara tidak sengaja menghancurkan array Anda?

(Peringatan anekdot: Saya pernah mendengar seseorang yang memiliki PXE diatur untuk menginstal otomatis Fedora terbaru. UPS-nya gagal. Setelah pemadaman listrik, servernya reboot dan diatur ke boot PXE dan ... menginstal Fedora di atas datanya. My titik? Hal-hal aneh terjadi. Untungnya, dia punya cadangan yang tepat.)

Lebih disukai, Anda memiliki setidaknya tiga salinan data Anda, satu disimpan sepenuhnya di luar kantor jika pusat data terbakar.

Snapshots yang diimplementasikan dengan benar HARUS didukung oleh penyimpanan Anda karena cadangan yang layak menggunakannya sebagai tahap pertama dalam menciptakan pekerjaan cadangan. Namun itu ide yang buruk untuk menggunakan snapshot untuk cadangan utama. Alasan:

1) Snapshots dan penyimpanan backend BISA gagal. Jadi backup yang sebenarnya harus menggunakan set spindle terpisah atau ada peluang besar untuk kehilangan set kerja primer dan data cadangan @ pada saat yang sama.

2) Snapshots "mengunyah" ruang yang dapat digunakan. Masuk akal untuk menggunakan penyimpanan yang mahal dan cepat untuk data panas saat ini dan snapshot dan backup yang tidak dimuat sebagai data dingin untuk beberapa penyimpanan yang lebih murah dan lebih lambat. Ini bekerja sangat baik dengan 1) BTW.

3) Snapshots biasanya memperlambat seluruh proses. Sebagian besar sistem menggunakan Copy-on-Write dan pendekatan ini menciptakan fragmentasi. Redirect-on-Write lebih cepat tetapi memakan banyak ruang. Sangat sedikit vendor yang menerapkan snapshot dengan benar. NetApp dengan WAFL dan Nimble Storage dengan CASL (Saya tidak terafiliasi dengan mereka). Hampir semua orang memiliki masalah. Misalnya Dell Equallogic memicu pembaruan halaman 15 MB (dan buang) pada setiap byte tunggal yang diubah. Itu MAHAL.

Ya itu. Ini adalah cara sempurna untuk menyimpan cadangan. Tidak ada lagi yang diperlukan, heck, bahkan melakukan cek ingtegrity hanya membuang-buang waktu.

Hanya untuk mengkonfirmasi - sebelum saya memberi saran lebih lanjut ... Anda bekerja untuk pesaing saya, bukan? Anda benar-benar melakukannya, yakin? Tidak? Oh

Maaf, Kacang. Tidak, tidak sama sekali. Maaf kawan.

Masalahnya adalah Anda benar-benar terbuka terhadap kesalahan yang terjadi pada (a) sistem dan (b) tingkat sistem operasi. Anda pada dasarnya hanya melindungi seseorang yang menghapus beberapa data. Bagus. Itu adalah kesalahan yang sering terjadi.

Apa yang tidak Anda lindungi adalah:

• Lonjakan listrik memusnahkan mesin. Pernah ke sana, melihat itu.
• Beberapa kontroler serangan raid yang rusak atau penulisan memori ** pada disk - ada apa pun.

Dan daftar panjang hal-hal lain.

Ini - tentu saja, kecuali jika Anda bekerja untuk pesaing saya - Anda selalu membuat cadangan:

• Di komputer lain
• Bahwa Anda mengisolasi setidaknya dari lonjakan listrik (bahkan jika Anda memiliki USV).

Inilah sebabnya kaset-kaset berbatu - mereka tidak terhubung dan apa pun yang pendek kebakaran atau banjir tidak akan melukai mereka. Lonjakan daya - lenyap tape reader dan mungkin robot tetapi kaset yang tidak ada di dalam reader tidak akan terpengaruh.

TERBAIK akan menjadi cadangan di luar kantor (apakah saya sudah menyebutkan hal-hal seperti kebakaran dan banjir?) (Sekali lagi, ketika Anda bekerja untuk pesaing - tidak ada yang namanya kebakaran gedung, sama sekali tidak diperlukan, seperti halnya asuransi kebakaran, tolong, simpan uang itu).

Sekarang, Anda mungkin berpikir "oh, banjir tidak pernah terjadi". Pastikan kamu yakin. Lihat, di sini adalah video 09.09.09 dari pusat data vodaphone. Saya yakin Anda akan mengerti di mana masalahnya untuk cadangan komputer insite / in:

http://www.youtube.com/watch?v=ttcQy3bCiiU

Pelajaran dari dua Drive RAID-1 gagal dalam waktu setengah jam satu sama lain: RAID tidak mekanisme cadangan, tidak dengan cara apa pun, bentuk atau bentuk.

RAID adalah mekanisme ketersediaan yang mengurangi waktu henti jika terjadi kegagalan perangkat keras, tetapi itu tidak akan membantu Anda sama sekali dalam hal misalnya, Virus, penghapusan / modifikasi data, atau kegagalan perangkat keras yang biasa-biasa saja.

Banyak administrator berpengalaman yang menggunakan apa yang dikenal sebagai aturan cadangan 3-2-1:

• Anda harus memiliki setidaknya tiga salinan data Anda, termasuk sumber utama. Yaitu cadangan tunggal tidak cukup dan salinan dalam sistem fisik yang sama tidak masuk hitungan.

• Anda harus menggunakan setidaknya dua metode cadangan yang berbeda.

• Anda harus memiliki setidaknya satu salinan data di luar situs.

Jepretan melanggar ketiga bagian:

• Anda hanya menggunakan satu mesin fisik. Apa pun yang memengaruhi seluruh mesin, seperti kegagalan PSU, dapat membawa serta semua data Anda.

• Anda hanya menggunakan satu metode untuk cadangan Anda. Jika ada yang salah dengan itu, Anda hanya akan mengetahui kapan memulihkan cadangan dalam situasi krisis.

• Anda tidak memiliki cadangan di luar situs. Banjir dan kebakaran hanya terjadi pada orang lain, sampai terjadi pada Anda ...

Karena itu:

• Anda harus memiliki setidaknya satu cadangan pada mesin terpisah di LAN Anda.

• Anda harus memiliki setidaknya satu cadangan yang tidak dihasilkan menggunakan snapshot. Mungkin tararsip inkremental yang bagus dan lama mungkin sudah beres? Atau rsyncsalinan berbasis?

• Anda harus memiliki setidaknya satu cadangan jarak jauh, sejauh mungkin dari lokasi Anda saat ini dan jelas tidak di gedung yang sama.

Juga harus ditunjukkan bahwa snapshot level blok memiliki jaminan konsistensi yang sama seperti menarik steker pada mesin Anda dan kemudian menyalinnya ke disk. Secara umum, Anda perlu menjalankan fscksetelah pemulihan atau berharap bahwa jurnal sudah cukup.

Snapshots tingkat sistem file harus lebih baik, tetapi mereka masih tidak akan menjamin konsistensi file Anda. Untuk banyak aplikasi (server database datang ke pikiran) menyalin file contoh langsung bisa sama sekali tidak berguna, karena mereka bisa dalam keadaan tidak konsisten. Anda akan perlu menggunakan mekanisme cadangan tingkat aplikasi mereka sendiri untuk memastikan keberadaan salinan bersih - di mana aturan 3-2-1 akan berlaku juga.

Akhirnya, ingatlah bahwa saat ini kami hanya berbicara tentang salinan data Anda saat ini . Untuk menjaga dari kegagalan (atau pelanggaran keamanan, dalam hal ini) yang berlangsung tanpa terdeteksi untuk beberapa waktu Anda juga perlu memiliki beberapa salinan data Anda di masa lalu untuk beberapa waktu yang lalu.

Sendiri itu bukan solusi cadangan sama sekali . Ini akan mengurangi atau menghapus downtime dalam skenario kegagalan tertentu tetapi tidak melindungi Anda sama sekali dari yang lainnya

Ini tentu saja dapat menjadi bagian yang sangat berharga dari ketersediaan yang lebih lengkap + solusi cadangan:

• RAID plus snapshow pada perangkat keras yang sama
• Salinan di tempat pada perangkat keras lain (ingat: ada mode kegagalan yang akan mengeluarkan seluruh kotak, pengontrol, drive, dan semuanya sekaligus)
• Salinan jarak jauh semi-terputus
• dan tentu saja salinan offline + offsite yang tepat untuk bencana yang sebenarnya

Juga: pastikan Anda secara teratur menguji cadangan Anda. Waktu terburuk untuk mengetahui cadangan Anda tidak berfungsi adalah ketika Anda perlu mengambil sesuatu darinya ...