Siap cadangan: menghancurkan mitos liburan



Mencadangkan bukanlah teknologi trendi yang diteriakkan dari setiap setrika. Itu harus ada di perusahaan yang serius, itu saja. Beberapa ribu server dicadangkan di bank kami - ini adalah pekerjaan yang rumit dan menarik, tentang beberapa seluk-beluknya, serta tentang kesalahpahaman umum tentang cadangan, saya hanya ingin memberi tahu.

Saya telah berurusan dengan topik ini selama hampir 20 tahun, dimana 2 tahun terakhir - di Promsvyazbank. Pada awal latihan saya melakukan backup hampir secara manual, dengan skrip yang hanya menyalin file. Kemudian, alat praktis muncul di Windows: Utilitas Robocopy untuk menyiapkan file dan NT Backup untuk menyalin. Dan kemudian tiba saatnya untuk perangkat lunak khusus, terutama Veritas Backup Exec, yang sekarang disebut Symantec Backup Exec. Jadi saya sudah terbiasa dengan cadangan untuk waktu yang lama.

Sederhananya, pencadangan adalah menyimpan salinan data (mesin virtual, aplikasi, database, dan file) untuk berjaga-jaga dengan keteraturan tertentu. Kasus apa pun biasanya memanifestasikan dirinya dalam bentuk perangkat keras atau kegagalan logis dan menyebabkan hilangnya data. Tugas dari sistem cadangan adalah untuk mengurangi kerugian dari kehilangan informasi. Kegagalan perangkat keras, misalnya, kegagalan server atau penyimpanan tempat database berada. Logis - ini adalah hilangnya atau perubahan sebagian data, termasuk karena faktor manusia: tidak sengaja menghapus tabel, file, meluncurkan skrip untuk mengeksekusi kurva. Ada juga persyaratan regulator untuk menyimpan jenis informasi tertentu untuk jangka waktu lama, misalnya, hingga beberapa tahun.



Daya tarik paling umum untuk cadangan adalah pemulihan salinan database yang disimpan untuk penyebaran berbagai sistem pengujian, klon untuk pengembang.

Ada beberapa mitos khas di sekitar cadangan yang sudah saatnya dihilangkan. Inilah yang paling terkenal di antara mereka.

Mitos 1. Cadangan telah lama menjadi fungsi kecil di dalam sistem keamanan atau penyimpanan.


Sistem cadangan masih merupakan kelas solusi yang terpisah, dan sangat independen. Bisnis yang terlalu penting dipercayakan kepada mereka. Bahkan, mereka adalah garis pertahanan terakhir dalam hal keamanan data. Jadi cadangan bekerja dengan kecepatannya sendiri, sesuai jadwal sendiri. Laporan harian dihasilkan di server, ada peristiwa yang bertindak sebagai pemicu untuk sistem pemantauan.



Selain itu, model peran akses ke sistem cadangan memungkinkan pendelegasian bagian dari otoritas kepada administrator sistem target untuk mengelola cadangan.

Mitos 2. Ketika ada RAID, cadangan tidak lagi diperlukan.




Tidak diragukan lagi, array RAID dan replikasi data adalah cara yang baik untuk melindungi sistem informasi dari kegagalan perangkat keras, dan jika ada server siaga, Anda dapat dengan cepat beralih ke sana jika terjadi kegagalan mesin utama.

Dari kesalahan logis yang dibuat oleh pengguna sistem, redundansi dan replikasi tidak disimpan. Ini adalah server siaga dengan rekaman tertunda - ya, ini bisa membantu jika ada kesalahan terdeteksi sebelum disinkronkan. Dan jika momen itu terlewatkan? Hanya cadangan yang dibuat tepat waktu yang akan membantu di sini. Jika Anda tahu bahwa data berubah kemarin, Anda dapat memulihkan sistem pada hari sebelum kemarin dan mengekstrak data yang diperlukan dari itu. Mengingat bahwa kesalahan logis adalah yang paling umum, cadangan lama yang baik tetap menjadi alat yang terbukti dan diperlukan.

Mitos 3. Cadangan adalah apa yang dilakukan sebulan sekali.


Frekuensi pencadangan adalah parameter yang dapat dikonfigurasi, terutama tergantung pada persyaratan sistem pencadangan. Sangat mungkin untuk menemukan data yang hampir tidak pernah berubah dan tidak terlalu penting, kehilangannya tidak akan penting bagi perusahaan.
Memang, mereka dapat dicadangkan sebulan sekali atau bahkan kurang. Tetapi lebih banyak data penting disimpan lebih sering, tergantung pada indikator RPO (Recovery point objrective), yang menentukan kehilangan data yang dapat diterima. Ini bisa seminggu sekali, sekali sehari, atau bahkan beberapa kali per jam. Kami memiliki log transaksi ini dari DBMS.



Ketika memperkenalkan sistem ke dalam operasi komersial, dokumentasi cadangan harus disetujui, yang mencerminkan poin utama, jadwal pembaruan, prosedur untuk memulihkan sistem, prosedur untuk menyimpan cadangan, dan sejenisnya.

Mitos 4. Volume salinan terus tumbuh dan menempati ruang yang dialokasikan sepenuhnya


Cadangan memiliki masa simpan terbatas. Tidak masuk akal, misalnya, untuk menyimpan semua 365 cadangan harian sepanjang tahun. Sebagai aturan, diperbolehkan untuk menyimpan salinan harian selama 2 minggu, setelah itu diganti dengan yang baru, dan versi yang dibuat pertama pada bulan tersebut tetap untuk penyimpanan jangka panjang. Itu, pada gilirannya, juga disimpan untuk waktu tertentu - setiap salinan memiliki seumur hidup.



Ada perlindungan terhadap kehilangan data. Aturan berlaku: sebelum cadangan dihapus, berikut ini harus dibentuk. Oleh karena itu, data tidak akan dihapus jika cadangan gagal, misalnya, karena tidak tersedianya server. Tidak hanya kerangka waktu yang dihormati, tetapi juga jumlah salinan di set dikontrol. Jika sistem mengatakan bahwa harus ada dua backup penuh, akan selalu ada dua, dan yang lama akan dihapus hanya ketika yang ketiga baru berhasil direkam. Jadi peningkatan volume yang ditempati oleh arsip cadangan hanya dikaitkan dengan peningkatan jumlah data yang dilindungi dan tidak tergantung pada waktu.

Mitos 5. Cadangan dimulai - semuanya menggantung


Lebih baik mengatakan ini: jika semuanya hang, maka tangan administrator tidak tumbuh dari sana. Secara umum, kinerja cadangan tergantung pada banyak faktor. Misalnya, dari kecepatan sistem cadangan itu sendiri: seberapa cepat ada penyimpanan disk, tape libraries. Dari kecepatan server sistem cadangan: apakah mereka mengelola untuk memproses data, melakukan kompresi dan deduplikasi. Serta kecepatan jalur komunikasi antara klien dan server.

Cadangan dapat masuk ke satu atau beberapa utas, tergantung pada apakah sistem redundan mendukung multithreading. Sebagai contoh, Oracle DBMS memungkinkan Anda untuk memberikan beberapa utas, sesuai dengan jumlah prosesor yang tersedia, hingga kecepatan transmisi bersandar pada batasan bandwidth jaringan.

Jika Anda mencoba membuat cadangan dengan sejumlah besar utas, yaitu kesempatan untuk membebani sistem kerja, itu akan benar-benar mulai melambat. Oleh karena itu, jumlah utas yang optimal dipilih untuk memberikan kinerja yang memadai. Jika bahkan sedikit penurunan kinerja sangat penting, maka ada opsi bagus ketika cadangan dilakukan bukan dari server pertempuran, tetapi dari klon - siaga dalam terminologi basis data. Proses ini tidak memuat sistem produksi utama. Data dapat diambil melalui sejumlah utas yang lebih besar, karena server tidak digunakan untuk pemeliharaan.

Dalam organisasi besar, jaringan terpisah dibuat untuk sistem cadangan sehingga cadangan tidak mempengaruhi penjualan. Selain itu, lalu lintas tidak dapat dikirim melalui jaringan, tetapi melalui SAN.

Kami mencoba mendistribusikan beban juga dari waktu ke waktu. Cadangan sebagian besar digunakan setelah jam kerja: di malam hari, di akhir pekan. Selain itu, mereka tidak memulai semuanya secara bersamaan. Cadangan mesin virtual adalah kasus khusus. Proses ini hampir tidak berpengaruh pada kinerja mesin itu sendiri, sehingga cadangan dapat tercoreng di siang hari, dan tidak menunda semuanya untuk malam itu. Ada banyak kehalusan, mengingat semuanya, cadangan tidak akan memengaruhi kinerja sistem.

Mitos 6. Meluncurkan sistem cadangan - inilah toleransi kesalahan.


Jangan pernah lupa bahwa sistem cadangan adalah garis pertahanan terakhir, yang berarti harus ada lima sistem lain di depannya yang memastikan kelangsungan, ketersediaan tinggi, dan stabilitas bencana infrastruktur TI dan sistem informasi perusahaan.

Tidak layak berharap bahwa cadangan akan memulihkan semua data dan dengan cepat meningkatkan layanan yang jatuh. Kehilangan data sejak saat pencadangan hingga saat kegagalan dijamin, dan data pada server baru dapat diunggah selama beberapa jam (atau berhari-hari, seperti yang diharapkan). Oleh karena itu, masuk akal untuk membuat sistem toleran kesalahan yang lengkap tanpa mengalihkan semuanya ke cadangan.

Mitos 7. Saya mengatur cadangan sekali, memeriksa apakah itu berfungsi. Tetap hanya untuk melihat log


Ini adalah salah satu mitos paling berbahaya, yang palsu yang Anda sadari hanya selama insiden itu. Catatan tentang cadangan yang berhasil bukan jaminan bahwa semuanya berjalan sebagaimana mestinya. Penting untuk memeriksa salinan yang tersimpan terlebih dahulu untuk penerapannya. Yaitu, mulailah proses pemulihan di lingkungan pengujian dan lihat hasilnya.

Dan sedikit tentang pekerjaan administrator sistem


Dalam mode manual, tidak ada yang telah menyalin data untuk waktu yang lama. IBS modern dapat mencadangkan hampir semua, Anda hanya perlu mengkonfigurasinya dengan benar. Jika server baru telah ditambahkan, daftarkan kebijakan: pilih konten yang akan dicadangkan, tentukan opsi penyimpanan, dan terapkan jadwal.



Pada saat yang sama, masih ada banyak pekerjaan karena armada server yang luas, termasuk basis data, sistem surat, cluster mesin virtual, dan sumber daya file pada Windows dan Linux / Unix. Karyawan yang mendukung sistem cadangan tidak duduk diam.
Untuk menghormati liburan ini, saya ingin semoga semua administrator memiliki keberanian, kejelasan gerakan, dan ruang tak terbatas untuk menyimpan cadangan!

Source: https://habr.com/ru/post/id446054/


All Articles