Hari ini, sekali lagi saya senang menyampaikan kepada Anda saran yang baik dari rekan saya Evgeny Ivanov, ketua tim dari tim dukungan teknis Veeam. Kali ini, Zhenya berbagi rekomendasi untuk bekerja dengan cadangan dan replika. Saya harap mereka membantu Anda menghindari kesalahan umum, dan replika serta cadangan Anda tidak akan pernah menjadi "tautan lemah" dalam proses pemulihan, jika perlu.

Jadi selamat datang di kucing.



Dalam artikel saya sebelumnya , kami menemukan cara untuk mengoptimalkan beban pada komponen infrastruktur cadangan, dan memeriksa kesalahan konfigurasi yang khas. Kami beralih ke topik penting lainnya - persiapan yang kompeten dan implementasi pemulihan. Kami juga akan menganalisisnya dengan contoh nyata yang telah didukung oleh tim dukungan teknis.

Backup tanpa restoran - uang sia-sia

Kami secara teratur dihubungi oleh pengguna yang menemukan diri mereka dalam situasi sulit yang serupa: perlu untuk melakukan pemulihan dari cadangan, tetapi ketika mereka mencoba melakukan ini, orang menemukan masalah yang tidak terpecahkan untuk mereka. Dan masalah ini sama sekali bukan kurangnya cadangan, aktivitas CryptoLocker atau semacamnya. Ini adalah "hanya" kurangnya perhatian untuk memeriksa cadangan dan replika untuk pemulihan. Banyak yang sering hanya berfokus pada proses pencadangan, lupa bahwa hanya memiliki cadangan bukanlah obat mujarab untuk kemungkinan masalah. Anda perlu memahami bahwa pemulihan adalah proses yang sama sekali berbeda, yang memiliki karakteristiknya sendiri, dan yang harus dipantau dan diuji sebelum diluncurkan dalam produksi. Berikut adalah beberapa contoh ilustrasi:

1. Pengguna mengalami kegagalan dalam pengoperasian mesin virtual kritis ukuran 20 TB. Downtime, tentu saja, tidak dapat diterima, dan admin memulai proses pemulihan instan (VM pemulihan instan) - setelah 5 menit mesin menyala. Tetapi kita ingat bahwa keadaan mesin ini hanya dapat digunakan sementara - harus dimigrasikan ke pusat data produksi. Dan dalam contoh ini, ternyata, kemampuan infrastruktur tidak memungkinkan untuk menyalin 20 TB data dalam waktu yang wajar. Dalam pengaturan proses pemulihan instan, dipilih untuk menyimpan perubahan pada drive C: dari server Veeam Backup & Replication (tidak seperti snapshot vSphere) - sebagai hasilnya, tentu saja, ruang kosong pada disk dengan cepat menjadi penuh. Pada saat pengguna menghubungi dukungan, VM memiliki perubahan yang tidak dapat diabaikan. Artinya, kami memiliki situasi di mana tidak mungkin untuk dengan cepat menyelesaikan proses pemulihan instan mesin kritis - bagaimana Anda dapat menyimpan data?
   
   Saya harus mengakui bahwa selama beberapa tahun terakhir saya tidak akan menyebutkan semua detail finalnya, tetapi saya ingat bahwa pada akhirnya kami tidak pernah menemukan sesuatu yang cemerlang. Klien di pihak mereka, paling tidak, memecahkan masalah ini dengan memperluas drive C: dari cadangan, menyalin file yang paling penting, dan kemudian mematikan VM dan bermigrasi. Secara umum, mukjizat tidak terjadi.
2. Pengguna memiliki satu pengontrol domain dalam infrastruktur, dan semua komponen Veeam Backup & Replication dikonfigurasikan menggunakan DNS. Ya, benar, Anda dengar juga. Ada seratus opsi untuk acara, tidak kurang, tetapi kenyataannya berjalan seperti ini: orang-orang merencanakan pemeliharaan dan memutuskan untuk beralih ke replika pengontrol domain mereka. Mereka melibatkan perpindahan terencana, yang, secara umum, direkomendasikan untuk dilakukan dalam situasi seperti itu. Pada tahap pertama, semuanya berjalan dengan baik, dan pada tahap kedua, VM asli dimatikan sebentar untuk mentransfer data yang tersisa. Tentu saja, pekerjaan peralihan segera berakhir dengan kesalahan, karena DNS berhenti bekerja.
   
   Untungnya, di sini kami dapat mengatasi situasi dengan mengaktifkan replika secara manual dari vSphere (sebenarnya, operasi ini tidak disarankan untuk dilakukan sendiri, seperti yang akan Anda lihat dari contoh berikut). Tetapi, seperti yang Anda pahami, proses pemeliharaan terganggu dan ditunda. Selain itu, kami harus memasukkan nama host secara manual di file C: \ Windows \ System32 \ drivers \ etc \ hosts di server Veeam Backup & Replication untuk memastikan kebenaran selama failover.
3. Klien lain memiliki seluruh infrastruktur cadangan yang dibangun di sekitar tape drive, dan hanya rantai pendek file yang disimpan pada disk. Ketika mereka perlu mengembalikan sejumlah file dari server file besar, ternyata tidak ada mesin yang dapat digunakan sebagai repositori tambahan ketika memulihkan dari tape, karena tidak ada cukup ruang kosong pada satu. (Anda dapat membaca tentang pemulihan dari pita magnetik secara langsung dan menggunakan repositori tambahan di sini (sejauh ini dalam bahasa Inggris)).

Saya pikir dalam ketiga contoh, pengguna, dapat dikatakan, terpikat oleh ilusi - mereka menyarankan bahwa jika cadangan berhasil, maka tidak akan ada masalah dengan pemulihan. Tapi ini, seperti yang Anda tahu, tidak selalu berarti demikian, dan oleh karena itu Anda perlu bersiap untuk pemulihan dengan hati-hati seperti yang Anda lakukan untuk cadangan. Untuk mulai dengan, ada baiknya mempelajari manual pengguna , yang berisi informasi yang cukup rinci tentang berbagai jenis pemulihan. Di awal setiap paragraf, persyaratan, langkah persiapan, dan batasan yang mungkin ada dicantumkan. Deskripsi pemulihan dari pita magnetik atau dari gambar perangkat keras sistem penyimpanan dapat ditemukan di bagian dokumentasi dan di artikel kami di Habré. Selain itu, langkah-langkah untuk mempersiapkan pemulihan objek aplikasi menggunakan alat Veeam Explorers dijelaskan di bagian “Perencanaan dan persiapan” manual untuk setiap alat. Saya sarankan Anda membacanya dengan saksama - ini akan membantu Anda mempersiapkan sistem dengan benar jika perlu. Dalam bahasa Rusia, instruksi untuk memulihkan basis data SQL Server diberikan di sini .

Mengapa Anda tidak perlu bekerja dengan replika dari konsol vSphere?

Secara teori, replika Veeam adalah mesin virtual biasa yang tampaknya logis untuk bekerja dengan menggunakan toolkit vSphere, khususnya, klien vSphere. Namun, kami tidak menyarankan melakukan ini, dan inilah alasannya: beralih ke replika di Veeam Backup & Replication adalah proses yang agak rumit yang memerlukan langkah-langkah yang sangat berurutan (sehingga Anda dapat memutar kembali langkah jika itu terjadi) dan langkah-langkah akhir yang benar - Anda cukup melihat gambar yang menggambarkan proses:



Jika Anda memutuskan untuk mengaktifkan replika dari klien vSphere, maka di masa mendatang Anda kemungkinan besar akan mengalami sejumlah masalah:

1. Beralih ke mekanisme replika dari Veeam Backup & replikasi (diperlihatkan dalam diagram) untuk mesin ini tidak lagi berfungsi.
2. Data dalam database Veeam Backup tidak akan sesuai dengan keadaan aktual VM. Dalam kasus terburuk, Anda perlu mengedit database untuk memperbaikinya.
3. Bahkan mungkin ada kehilangan data, seperti dalam contoh ini: pengguna secara manual menyalakan replika di klien vSphere dan memutuskan untuk terus bekerja dengannya. Setelah beberapa saat, ia menyadari bahwa replika itu masih ditampilkan di konsol Veeam Backup & Replication, dan memutuskan untuk menghapusnya sebagai tidak perlu. Saya mengkliknya dengan tombol kanan dan memberi perintah "Hapus dari disk" . Veeam Backup & Replication segera menghapus replika dari disk, yang, untuk sesaat, sudah digunakan penuh sebagai VM biasa dan berisi data yang diperlukan dan berguna.

Tentu saja, ada situasi di mana Anda masih harus mengaktifkan replika dari klien vSphere - sebagai aturan, ini adalah kasus ketika server Veeam dimatikan dan replika perlu dinyalakan dengan penundaan. Tetapi jika semuanya sesuai dengan server Veeam, maka Anda harus bekerja dengan replika dari konsolnya.

Juga, jangan hapus replika menggunakan klien vSphere. Veeam Backup & Replication akan tetap tidak menyadari perubahan seperti itu, dan ini penuh dengan kesalahan dan data yang sudah ketinggalan zaman. Jika Anda tidak lagi membutuhkan replika, hapus menggunakan Veeam console, dan bukan sebagai VM dari klien vSphere. Jadi, Anda akan selalu memiliki daftar replika terbaru.

"O" - hati-hati, perbarui!

Di sini yang kami maksud, tentu saja, pembaruan untuk hypervisor dan berbagai aplikasi yang didukung menggunakan Veeam. Jika Anda melihatnya dari sudut pandang bekerja dengan Veeam Backup & Replication, maka pembaruan dapat dibagi menjadi 2 kategori: besar, serius, membawa banyak perubahan - dan kecil.

Pertimbangkan dulu kategori pertama.

Pembaruan paling penting adalah yang dirancang untuk hypervisor. Sebelum Anda menginstal pembaruan seperti itu, Anda harus memastikan bahwa itu didukung oleh Veeam Backup & Replication. Pembaruan semacam itu membawa banyak perubahan pada pustaka dan API yang Veeam Backup & Replication gunakan, jadi untuk mengumumkan dukungan mereka secara resmi, Anda perlu memperbarui kode Veeam Backup & Replication dan melakukan pengujian yang ketat.

Kita juga harus ingat bahwa, misalnya, VMware tidak menyediakan akses awal ke versi terbaru vSphere untuk produsen perangkat lunak, sehingga pengembang dan penguji Veeam menerima versi baru pada saat yang sama dengan umat manusia progresif - oleh karena itu, biasanya antara rilis VMware dan dukungan yang diumumkan secara resmi. waktu tertentu. Jumlah dan variasi perubahan yang diperlukan untuk membuat perbaikan terbaru yang sederhana agar sesuai dengan peluang mereka kecil - dan dukungan resmi, sebagai suatu peraturan, diumumkan bersamaan dengan rilis versi rilis Veeam Backup & Replication.

Akibatnya, ada saat yang canggung ketika, setelah rilis versi baru vSphere, jumlah aplikasi untuk dukungan teknis meningkat tajam, karena pengguna terburu-buru untuk menginstal versi baru, dan cadangan mereka, tentu saja, segera berhenti bekerja segera. Kami, dukungan teknis Veeam, harus menjelaskan kepada pengguna apa kesalahan mereka, meminta mereka untuk mundur (jika mungkin), atau memikirkan cara rumit untuk memecahkan kebuntuan. Karena itu, sebelum menginstal pembaruan besar, pastikan untuk memeriksa kompatibilitasnya dengan perangkat lunak yang berjalan di komputer Anda, saya mohon!

Semua hal di atas berlaku untuk aplikasi yang Anda cadangkan dan berharap untuk pulih menggunakan Veeam. Lini alat Veeam Explorers juga memiliki daftar versi yang didukung dari masing-masing aplikasi, yang diperbarui dengan setiap rilis Veeam Backup & Replication. Oleh karena itu, sebelum menginstal versi baru aplikasi Anda - apakah itu Exchange, Oracle atau SharePoint - pastikan untuk membaca kembali bagian yang sesuai dari dokumentasi Veeam Explorers .

Untuk kategori kedua, yaitu Saya merujuk pada pembaruan kecil, misalnya, versi baru Alat VMware, pembaruan Exchange kumulatif, pembaruan keamanan vSphere, dll. Biasanya, mereka tidak membawa modifikasi besar apa pun, dan dalam kebanyakan kasus, Veeam Backup & Replication tidak mengalami masalah dengannya. (Oleh karena itu, tidak ada pengumuman publik tentang dukungan resmi untuk produk untuk mereka.) Namun, dalam praktik kami ada kasus-kasus ketika pembaruan tersebut telah secara signifikan mengubah hal-hal biasa yang menyebabkan kesalahan dalam Veeam Backup & Replikasi. Dalam situasi seperti itu, setelah mengkonfirmasi masalah, insinyur Veeam mencoba untuk dengan cepat merilis perbaikan terbaru.


Seperti yang Anda pahami, tambalan dan pembaruan dapat menyebabkan masalah tidak hanya dengan cadangan, tetapi juga dengan aplikasi yang membuat cadangan ini. Dan di sini laboratorium virtual - Veeam DataLabs akan membantu Anda. Anda mungkin pernah mendengar tentang fungsi SureBackup, yang dirancang untuk memverifikasi cadangan. Ini didasarkan tepat pada penggunaan DataLabs, dengan penciptaan lingkungan yang terisolasi di mana Anda dapat, khususnya, menguji pembaruan sebelum menginstalnya dalam produksi. Saya sangat menyarankan Anda untuk melakukannya - selamatkan diri Anda dari banyak sel saraf. Dan jika orang lain tidak tahu tentang SureBackup, saya sarankan membaca dokumentasinya .

Mungkin untuk hari ini saya memiliki segalanya, terima kasih atas perhatian Anda!

Apa lagi yang harus dibaca

Artikel tentang Habré:

• Satu kasus di Pixar atau sekali lagi tentang pentingnya pengujian cadangan
• Fitur penyimpanan cadangan jangka panjang
• Praktik Terbaik untuk Kebijakan Cadangan
• Rekomendasi untuk kebijakan cadangan dan pemulihan setelah Kiamat

User Manual (dalam bahasa Rusia)