Apakah saya masih memerlukan cadangan jika saya memiliki sistem penyimpanan redudant dengan kemampuan rollback?


32

Organisasi saya baru-baru ini membeli sistem penyimpanan. Ini memiliki 1.5Petabyte, dengan RAID6, dan ada cermin yang disinkronkan secara online di lokasi yang berbeda secara fisik.

Sistem ini memungkinkan pemulihan rollback / file, secara default memungkinkan hingga 30 hari tetapi ini dapat ditingkatkan.

Ada diskusi yang terjadi jika kita membutuhkan semacam cadangan tambahan untuk data yang hanya tinggal di penyimpanan.

Sistem ini memiliki tingkat redundansi yang sangat baik, memiliki redundansi geografis dan memungkinkan hingga batas tertentu rollback yang berarti kita dapat memulihkan hingga waktu yang ditentukan (30 hari secara default) data lama atau data yang terhapus secara tidak sengaja.

Mengingat skenario ini apakah masuk akal untuk memiliki cadangan "tradisional"? Secara tradisional, maksud saya adalah sistem cadangan khusus, dengan snapshot yang dapat kita ambil jika terjadi kesalahan.

Apakah kita benar-benar membutuhkannya? Apakah saya melewatkan sesuatu? Apakah saya hanya berpikir dengan cara tradisional dan terlalu bersemangat?


Jika itu juga memungkinkan Anda untuk mereplikasi foto ke perangkat lain maka Anda dapat mengatasi masalah yang Sven sebutkan dalam jawabannya.
Drifter104

4
Pasti terkait, tetapi mungkin bukan duplikat langsung karena pemisahan geografis dan kemampuan snapback rollback: Mengapa RAID bukan cadangan?
CVn

Selama Anda juga menghapus tombol "hapus" dari setiap keyboard di tempat itu, berarti Anda emas ;-)
Tom Newton

1
Tentu lebih baik daripada tidak memilikinya. Saya masih lebih suka bahwa cadangan hidup pada media jauh dari "kesalahan orang" hidup. Namun, Anda tahu jawaban untuk pertanyaan Anda, tetapi itu melibatkan penetapan harga pada data Anda. Semoga berhasil.
Tom Newton

7
Apakah kemampuan "rollback" Anda juga mencakup perubahan volume? Misalnya, apakah ini dapat dipulihkan jika seseorang menghapus semua volume?
vhu

Jawaban:


40

Apa yang Anda jelaskan adalah RAID yang didistribusikan secara geografis dan RAID tidak pernah merupakan cadangan .

Sinkronisasi online biasanya berarti semua yang Anda lakukan pada penyimpanan utama segera direplikasi ke sistem cadangan, termasuk operasi seperti penghapusan (semua) foto dan / atau volume oleh penyerang atau hanya kesalahan admin.


3
Atau, karena kedua penyimpanan mungkin menggunakan OS yang sama, bug perangkat lunak dapat menghancurkan data. Tidak mungkin, kesalahan admin lebih mungkin, tetapi mungkin.
Sunzi

8
Benar. Tujuannya agar tidak ada yang bisa mengelola snapshot otomatis. Itu harus memberikan tingkat ketahanan terhadap kesalahan. Tentu saja orang juga dapat menghapus cadangan secara tidak sengaja.
nsn

2
@nsn ada banyak kegagalan terkait lainnya seperti bug pada perangkat lunak perangkat atau bug dalam skrip manajemen Anda. Tanpa cadangan di tempat lain Anda mempercayakan pekerjaan Anda kepada vendor ... Apakah Anda bersedia melakukan itu? Juga menghitung kerusakan jika terjadi kehilangan. Mungkin jawabannya tergantung pada seberapa berharganya data tersebut. Apakah perusahaan hilang tanpa itu?
usr

2
@ nsn > Tentu saja orang juga dapat menghapus cadangan secara tidak sengaja. < - ya tetapi menjadi jauh lebih sulit ketika cadangan diambil offline dan ditempatkan di penyimpanan offsite yang aman, misalnya.
Rob Moir

7

Rollback 30 hari adalah kemampuan yang hebat, tetapi bagaimana jika "file-kritis-penting-xyz" menjadi rusak / rusak dan ini tidak terdeteksi hingga 31+ hari kemudian? Situasi ini adalah perbedaan antara jadwal pencadangan dan pengarsipan, tetapi dalam uraian Anda yang terakhir tidak disebutkan. Sistem pengarsipan biasanya disimpan dalam pita biaya sangat rendah. Juga tidak ada informasi yang tersedia tentang apakah bisnis ini memiliki peraturan atau persyaratan lain untuk menyimpan data selama lebih dari 30 hari, yang sering terjadi.

Jika ini tidak berlaku untuk situasi Anda, maka Anda harus baik.


3
Ya benar. 30 hanyalah standar yang dapat kita atur nilai lainnya. Bagaimanapun, penyimpanan offline juga membutuhkan uang dan tidak menempel selamanya. Akan selalu ada hari n +1
nsn

2
Saya suka memiliki 30 hari bergulir, ditambah bulanan untuk tahun lalu, ditambah tahunan. Saya sudah memiliki sejumlah file (yang penting dan lama) lenyap dan tidak terdeteksi dalam periode waktu bergulir. Cadangan tahunan dapat menghemat hidup.
Brian Knoblauch

@BrianKnoblauch: Ya, skema semacam itu adalah ide yang bagus, baik untuk snapshot online atau cadangan offline.
Ben Voigt

6

Memiliki mesin yang terpisah secara geografis, keduanya memiliki data yang baik.

Apa yang terjadi ketika Anda mengalami beberapa kegagalan yang melibatkan kedua atau semua situs Anda? Kebakaran di satu, pencurian server di yang lain? Atau ada masalah dengan garis di antara mereka, maka server lokasi utama padam, dan pengontrol HD menjadi kera dan menulis sampah? Atau orang dalam melakukan tindakan jahat pada keduanya? Atau FBI menyita server Anda di kedua lokasi karena dicurigai (Anda tidak akan pernah, tetapi, mungkin Anda di-host di pusat data dengan schmucks). Atau .. Saya diingatkan tentang beberapa pemadaman "cloud" profil tinggi di mana semuanya mubazir, dianalisis hingga tingkat ke-n, tetapi, tetap saja, ada yang salah. Saya akan memberi Anda ini semua tidak mungkin, tetapi Anda telah mengakui bahwa hal-hal yang tidak mungkin dapat terjadi.

Jadi, seberapa penting / bernilai data itu? Apa yang akan dilakukan organisasi jika akhirnya hilang?


3
Jika Anda memiliki dua lokasi dan Anda kehilangan keduanya maka Anda mungkin juga kehilangan cadangan Anda. Sebagian besar jawaban ini adalah argumen untuk replikasi di lebih dari dua situs, bukan argumen yang mendukung pencadangan.
Ben

2
Itu berlangsung selamanya. Setiap kali Anda menambahkan level redundansi, Anda selalu dapat mengharapkannya gagal (baik secara geografis, atau hanya disk). Jika Anda memiliki n disk yang redundan, Anda selalu dapat bertanya "bagaimana jika n +1 rusak". Anda dapat memiliki api di ruang server Anda dan di ruang cadangan Anda juga. Pekerjaan orang dalam juga bisa menyerang keduanya. Tidak ada 100% sistem yang gagal. Masalahnya di sini adalah untuk mengetahui apakah pengaturan seperti itu dapat setara dengan server "tradisional" + cadangan
2015

1
Saya pikir @nsn membuat poin yang bagus, tetapi saya juga berpikir bahwa pelajaran dari banyak jawaban ini adalah memiliki cadangan Anda pada infrastruktur teknologi terpisah dari media penyimpanan Anda adalah ide yang baik, karena itu membuat jauh lebih sulit untuk teknologi. kegagalan untuk menyebarkan, dan lebih sulit bagi aktor jahat untuk menginfeksi keduanya (tetapi hanya lebih sulit). Kami secara teratur melihat bug dalam sistem redundan yang menyebabkan kaskade kegagalan. Memiliki solusi / vendor berbeda yang terlibat membantu. Lindung nilai ini masih berlangsung, tetapi saya menganggap bahwa tingkat pemisahan teknologi menjadi kewaspadaan yang wajar dalam banyak kasus.
Nick

@Nick, saya pikir Anda memiliki komentar yang sangat valid. Saya akan menjawabnya.
nsn

4

Pertanyaan di sini tampaknya tentang seberapa terputus dan berbeda secara geografis salinan yang direplikasi dari data Anda sebelum menjadi cadangan dan bukan ketersediaan tinggi / infrastruktur redundansi. Perasaan saya adalah Anda sudah dekat, tetapi masih membutuhkan cadangan.

Untuk menyatukan (memilih-ceri) beberapa pemikiran dalam jawaban dan komentar yang lain, Anda dapat pergi jauh-jauh ke jalan "baik, teknologi X tidak mencakup skenario bencana Y, jadi itu bukan cadangan," dan di beberapa titik Anda perlu memutuskan apa yang masuk akal untuk Anda, yang tampaknya menjadi alasan Anda bertanya. Perasaan saya tentang ini, dan saya pikir perasaan banyak komentator, adalah bahwa cadangan Anda perlu ada pada infrastruktur teknologi yang terpisah dari data Anda yang sedang digunakan sehingga kegagalan, kecelakaan, dan tindakan jahat tidak dapat menyebar atau memiliki rintangan yang jauh lebih tinggi untuk disilangkan. Contoh yang diberikan dalam komentar adalah seseorang menghapus volume, yang merupakan skenario yang valid, bukan pie-in-the-sky menurut saya. Tapi selain itu, contoh dunia nyata dari pekerjaan saya. Universitas tempat saya bekerja (tapi untungnya tidak untuk mengelola infrastruktur ini untuk) memiliki beberapa infrastruktur virtualisasi ketersediaan tinggi yang serius yang mendukung banyak fasilitas kampus. Ada di beberapa situs, tetapi semuanya berjalan pada platform satu vendor. Suatu bug yang tidak jelas muncul pada suatu hari yang menyebabkan kegagalan kaskade yang pertama kali menurunkan satu server, kemudian ketika bebannya bergeser, ia mengambil sisa situs itu, dan kemudian ketika bebannya bergeser lagi, ia mengeluarkan hosting situs lain infrastruktur itu. (Saya percaya mereka telah menyelesaikan masalah ini sejak saat itu). Data tidak hilang dalam kasus ini, tetapi layak untuk membayangkan skenario yang melibatkan data Anda di mana itu. Suatu bug yang tidak jelas muncul pada suatu hari yang menyebabkan kegagalan kaskade yang pertama kali menurunkan satu server, kemudian ketika bebannya bergeser, ia mengambil sisa situs itu, dan kemudian ketika bebannya bergeser lagi, ia mengeluarkan hosting situs lain infrastruktur itu. (Saya percaya mereka telah menyelesaikan masalah ini sejak saat itu). Data tidak hilang dalam kasus ini, tetapi layak untuk membayangkan skenario yang melibatkan data Anda di mana itu. Suatu bug yang tidak jelas muncul pada suatu hari yang menyebabkan kegagalan kaskade yang pertama kali menurunkan satu server, kemudian ketika bebannya bergeser, ia mengambil sisa situs itu, dan kemudian ketika bebannya bergeser lagi, ia mengeluarkan hosting situs lain infrastruktur itu. (Saya percaya mereka telah menyelesaikan masalah ini sejak saat itu). Data tidak hilang dalam kasus ini, tetapi layak untuk membayangkan skenario yang melibatkan data Anda di mana itu.

Anda ingin cadangan Anda kebal terhadap semua itu, dan bahkan dapat diakses saat infrastruktur itu sedang rusak. Jika data tidak tersedia selama seminggu saat RAID Anda membangun kembali, dapat memulihkan dokumen penting bisnis dari cadangan itu bagus (meskipun tidak diperlukan). Jika RAID Anda menghilang, kemudian direplikasi ke situs Anda yang lain, Anda benar-benar ingin cadangan itu berasal dari vendor terpisah atau pada beberapa media seperti tape yang terisolasi.

Semua ini berkata, saya akan mengulangi lagi bahwa cadangan Anda harus pada infrastruktur terpisah dari data Anda. Ada banyak tingkat isolasi di sini, tapi saya pikir apa pun yang terhubung melalui replikasi langsung terlalu dekat untuk dijadikan cadangan. Anda akan menginginkan sesuatu sebagai tambahan.


1

Asumsi: sistem penyimpanan akan digunakan oleh banyak aplikasi.

Saya menganggap Anda akan melakukan jauh lebih baik dengan sistem cadangan terpisah.

RAID dan mirroring bukan cadangan tetapi fitur bawaan rollback dapat menggantikan sistem cadangan tradisional.

TAPI:

Saya lebih suka kebijakan pemulihan berbasis aplikasi / data dan bukan berbasis penyimpanan karena:

  1. aplikasi memiliki persyaratan berbeda terkait dengan pemulihan dan kehilangan data yang dapat diterima (beberapa di antaranya diberlakukan oleh berbagai peraturan: media hanya baca, enkripsi, tahan X tahun terakhir, dll),
  2. beberapa aplikasi memiliki (sangat) alat pencadangan dan pemulihan yang baik (oracle, mssql) builtin dan direkomendasikan cara untuk melakukan bagian pencadangan / pemulihan (sebagai DBA Oracle, saya lebih suka dan saya akan melakukan semua pencadangan yang terkait dengan Oracle dengan rman).
  3. pertumbuhan, penggunaan ruang Anda dapat tumbuh lebih cepat dari yang Anda harapkan, sekarang sistem ini dapat menampung 30 hari data rollback, ini tidak dijamin di masa depan
  4. lebih murah, biaya menggunakan kaset yang lebih besar untuk mengakomodasi kebijakan cadangan / pemulihan, setelah beberapa tahun pertumbuhan, akan lebih kecil daripada biaya untuk membeli disk baru yang lebih besar untuk menghormati jendela rollback yang sama seperti sekarang
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.