Bab 7. Mencadangkan dan memulihkan data menggunakan Acronis True Image Home Ada banyak produk pencadangan dan pemulihan yang tersedia di pasaran saat ini, dan kami telah menemukan beberapa di antaranya di

Cadangan data adalah fitur penting bagi setiap pengguna komputer yang bertanggung jawab. Tidak ada yang lebih buruk daripada menyadari sambil duduk di depan komputer bahwa hasil pekerjaan bulanan atau file penting Anda baru saja hilang, yang tidak ada cara untuk memulihkannya.

Data seringkali sangat berharga. Dan tidak masalah jika ini adalah file atau informasi pribadi yang digunakan untuk bekerja. Mari kita lihat fitur apa untuk pencadangan dan pemulihan data Pengembang Microsoft yang dilengkapi dengan versi terbaru dari sistem operasi mereka - Windows 10, dan juga mempertimbangkan kemungkinan mencadangkan pemulihan data menggunakan program pihak ketiga.

Cadangan Data: Apa itu?

Pencadangan file

Kami terkadang mendengar tentang perlunya "mencadangkan komputer Anda". Tetapi tidak sepenuhnya benar untuk mengatakan demikian, karena ada dua cara untuk mencadangkan data. Pertama, membuat salinan cadangan file, yang dengannya Anda dapat membuat salinan file dan folder individual yang disimpan di komputer atau media penyimpanan lainnya. Setiap pengguna yang memiliki data penting yang tersimpan di komputer harus mencadangkannya di hard drive eksternal jika sumber aslinya hilang atau terhapus.

Cadangan sistem

Cara lain untuk membuat cadangan data dikenal sebagai System Backup atau System Image. Ini adalah cara yang lebih rumit untuk mencadangkan data, karena dalam kasus ini kita berbicara tentang membuat salinan seluruh sistem operasi komputer tertentu, bersama dengan program, file, dan pengaturan. Cadangan sistem digunakan untuk memulihkannya jika Windows menjadi tidak stabil atau berhenti bekerja sama sekali.

Cadangan Windows dapat menghabiskan ratusan gigabyte penyimpanan. Tetapi menggunakan perangkat lunak pencadangan data khusus, Anda dapat mengonfigurasi fungsi untuk menyimpan hanya perubahan yang telah dibuat sejak pencadangan terakhir sistem.

Mencadangkan dan memulihkan data menggunakan Windows

Windows 10 memiliki alat bawaan yang dirancang untuk membuat salinan cadangan file dan sistem, serta memulihkan informasi dengan bantuan mereka. Banyak pengguna tidak menggunakannya, tidak mengetahui keberadaan mereka atau cara mengkonfigurasinya dengan benar. Mereka lebih cenderung menggunakan program pihak ketiga daripada alat yang dibangun ke dalam sistem operasi.

Riwayat berkas

oleh sebagian besar secara sederhana mencadangkan file dan folder, serta memulihkannya, adalah Riwayat File. Dengan fungsi ini, Anda dapat menyalin data secara teratur, sesuai dengan jadwal yang ditentukan pengguna, dan menyimpannya ke keras eksternal disk atau media penyimpanan eksternal lainnya. Salinan file juga dapat disimpan ke hard drive komputer (walaupun ini bertentangan dengan aturan dasar pencadangan).

Untuk mengatur Riwayat File, buka menu Mulai dan pilih Pengaturan. Di menu Opsi yang terbuka, buka Pembaruan & Keamanan / Layanan Cadangan.

Di sisi kanan panel, di bagian Cadangkan menggunakan riwayat file, klik Tambah Disk. Anda akan diminta untuk memilih salah satu media penyimpanan eksternal yang terhubung ke komputer Anda. Pilih salah satu yang ingin Anda cadangkan datanya dan atur parameter pengarsipan: interval untuk menyimpan salinan file dan durasi penyimpanannya, jika perlu, Anda dapat menentukan folder tertentu untuk salinan file yang ingin Anda buat atau hapus yang tidak perlu.

Selama pencadangan, Riwayat File juga secara otomatis menyalin semua folder akun pengguna: Gambar, Dokumen, Unduhan, dll.

Fitur ini dapat dimatikan kapan saja, tetapi agar data yang ditentukan pengguna dapat dicadangkan pada interval waktu yang ditentukan, Pencadangan File Otomatis harus diaktifkan.

Secara default, file dicadangkan setiap jam. Waktu minimum yang dapat diatur adalah 10 menit, maksimum adalah Harian. Anda juga dapat mengatur durasi penyimpanan cadangan: dari satu bulan hingga saat ruang kosong diperlukan (dalam hal ini, cadangan lama akan dihapus secara otomatis untuk memberi ruang bagi cadangan baru).

Memulihkan file dari cadangan

Untuk memulihkan file dari drive cadangan, buka Control Panel dan pilih menu File History.

Di kolom kiri jendela yang terbuka, pilih Pulihkan file pribadi, navigasikan ke folder dan temukan file yang perlu Anda pulihkan. Untuk memulihkan file, klik tombol hijau di bawah dan tentukan jalur untuk memulihkannya. Versi salinan cadangan file berdasarkan tanggal dan waktu penyimpanannya dapat dipilih dengan menekan tombol dari panah kanan dan kiri.

Layanan awan OneDrive

Cara lain untuk melindungi diri Anda dari kehilangan file penting adalah dengan mentransfernya ke penyimpanan cloud dan menyinkronkannya dengan komputer Anda. Ada banyak penyimpanan seperti itu: Dropbox, google Drive dll. Namun fitur Windows versi terbaru (10, 8, 8.1) adalah hadirnya layanan cloud Microsoft sendiri yang dibangun ke dalam sistem operasi yang disebut OneDrive.

Saat menggunakan salah satu layanan cloud, mereka biasanya membuat folder di disk komputer dengan nama mereka sendiri, file yang disinkronkan. V versi terbaru folder jendela OneDrive ada secara default, mis. Layanan ini tersedia untuk setiap pengguna segera setelah menginstal sistem operasi.

File apa saja. yang akan disimpan ke folder ini akan segera disalin ke penyimpanan cloud dan disinkronkan dengannya. Pengguna juga dapat mengakses file dalam folder ini dari perangkat lain, cukup buka akun OneDrive Anda dari perangkat tersebut.

Titik Pemulihan

Sisi lain dari pencadangan dan pemulihan Data Windows 10, ada pemulihan file sistem dan kinerja sistem operasi. Membuat dan memulihkan cadangan sistem operasi adalah proses yang lebih rumit dibandingkan dengan file dan folder pribadi pengguna. Tetapi untuk ini, Windows 10 menyediakan fungsi khusus - Pemulihan Sistem. Dengan bantuannya, pengguna dapat mengembalikan sistem operasi ke kapasitas kerja dengan "memutar kembali" ke status awal yang disimpan - Titik Pemulihan.

Secara default, fitur pemulihan di sistem operasi tidak diaktifkan. Agar dapat menggunakannya, itu harus dikonfigurasi. System Restore bekerja dengan membuat Restore Points, yang menyimpan status Windows pada titik waktu tertentu. Seiring dengan pengaturan dan status sistem operasi, Titik Pemulihan mencakup: aplikasi yang diinstal(Sebagai contoh, Microsoft Office) dan driver perangkat (misalnya, kartu video).

Pengguna dapat membuat titik pemulihan kapan saja. Itu juga dibuat secara otomatis jika Anda menginstal beberapa aplikasi di komputer Anda atau mengunduh pembaruan sistem, dll. Tetapi ingat bahwa Pemulihan Sistem tidak memulihkan file pribadi pengguna.

Jika Anda mulai memperhatikan bahwa sistem operasi tidak berfungsi dengan benar atau dengan kegagalan dan kesalahan, maka Anda dapat menjalankan salah satu titik pemulihan yang disimpan sebelumnya dan Windows akan kembali ke status pada saat pembuatannya.

Untuk melakukan ini, buka Control Panel dan pilih menu Recovery / System Recovery Settings / Customize, yang dengannya Anda mengaktifkan dan mengonfigurasi fungsinya.

Untuk mengembalikan Windows dari restore point, masuk ke Control Panel dan pilih menu Recovery / Start System Restore, pilih restore point yang diperlukan dan klik Next.

Gambar Sistem

Mungkin fitur pencadangan Windows yang paling dasar dan kompleks adalah fitur yang disebut System Image.

Dengan menggunakan opsi ini, Anda dapat membuat "duplikat" dari seluruh disk komputer, termasuk Windows 10, serta semua program dan data pribadi pengguna. Gambar sistem disimpan ke hard drive eksternal, dari mana, jika diperlukan atau kegagalan komputer, itu digunakan kembali ke hard drive komputer. Akibatnya, pengguna menerima versi sistem operasi yang berfungsi, bersama dengan program dan file.

Ini sangat fitur yang berguna, tetapi kelemahannya adalah pengguna tidak memiliki kemampuan untuk memulihkan file individual dari citra sistem, seperti dari Riwayat File. Anda hanya dapat memperluas seluruh gambar sepenuhnya. Oleh karena itu, pengguna sering menggunakan fungsi-fungsi ini secara paralel.

Untuk membuat System Image, buka Control Panel dan pilih menu File Backup and Restore. Di kolom di sebelah kiri, klik Buat gambar sistem, dan pilih drive tempat Anda ingin menyimpannya. Perlu diingat bahwa System Image biasanya berukuran besar.

Untuk memulihkan sistem dari Gambar Sistem, buka Pengaturan Sistem / Pembaruan dan Keamanan / Pemulihan, dan pilih opsi boot khusus. Setelah Windows 10 reboot, pilih System Image Recovery dari menu yang disediakan.

Program pencadangan dan pemulihan lainnya File Windows 10

ALEXEY BEREZHNY, Administrator sistem. Kegiatan utama: virtualisasi dan jaringan heterogen. Hobi lain selain menulis artikel adalah mempopulerkan software gratis.

Cadangan
Teori dan praktek. Ringkasan

Untuk mengatur sistem pencadangan dengan paling efektif, Anda perlu membangun strategi nyata untuk menyimpan dan memulihkan informasi.

Pencadangan (atau, sebagaimana disebut juga, pencadangan - dari kata bahasa Inggris "cadangan") adalah proses penting dalam kehidupan struktur TI apa pun. Ini adalah parasut untuk penyelamatan jika terjadi bencana yang tidak terduga. Pada saat yang sama, cadangan digunakan untuk membuat semacam arsip sejarah kegiatan bisnis perusahaan selama periode tertentu dari hidupnya. Bekerja tanpa cadangan seperti tinggal di udara terbuka - cuaca dapat memburuk kapan saja, dan tidak ada tempat untuk bersembunyi. Tetapi bagaimana cara mengaturnya dengan benar agar tidak kehilangan data penting dan tidak menghabiskan banyak uang untuk itu?

Biasanya, artikel tentang topik mengatur pencadangan terutama difokuskan pada solusi teknis, dan hanya sesekali perhatian diberikan pada teori dan metode mengatur penyimpanan data.

Dalam artikel ini, kita akan berbicara tentang kebalikannya: perhatian utama diberikan pada konsep umum, dan sarana teknis hanya akan disinggung sebagai contoh. Ini akan memungkinkan kita untuk abstrak dari perangkat keras dan perangkat lunak dan menjawab dua pertanyaan utama: "Mengapa kita melakukan ini?", "Bisakah kita melakukan ini lebih cepat, lebih murah dan lebih andal?".

Maksud dan tujuan pencadangan

Dalam proses mengatur pencadangan, dua tugas utama ditetapkan: pemulihan infrastruktur jika terjadi kegagalan (Pemulihan Bencana) dan memelihara arsip data untuk selanjutnya menyediakan akses ke informasi untuk periode yang lalu.

Contoh klasik pencadangan untuk Pemulihan Bencana adalah citra partisi sistem server yang dibuat oleh Acronis True Image.

Contoh arsip dapat berupa unggahan basis data bulanan dari 1C, direkam pada kaset dengan penyimpanan berikutnya di tempat yang ditentukan secara khusus.

Ada beberapa faktor yang membedakan backup untuk pemulihan cepat dari arsip:

• Periode penyimpanan data. Untuk salinan arsip, cukup panjang. Dalam beberapa kasus, itu diatur tidak hanya oleh persyaratan bisnis, tetapi juga oleh hukum. Untuk salinan pemulihan bencana, itu relatif kecil. Biasanya, satu atau dua (dengan peningkatan persyaratan untuk keandalan) cadangan untuk Pemulihan Bencana dibuat dengan interval maksimum satu atau dua hari, setelah itu ditimpa dengan yang baru. Dalam kasus yang sangat kritis, Anda juga dapat memperbarui cadangan untuk pemulihan bencana lebih sering, misalnya, setiap beberapa jam sekali.
• Kecepatan akses data. Kecepatan akses ke arsip jangka panjang tidak penting dalam banyak kasus. Biasanya, kebutuhan untuk "mengumpulkan data untuk periode" muncul pada saat rekonsiliasi dokumen, kembali ke versi sebelumnya dll., yaitu, tidak dalam mode darurat. Hal lain adalah pemulihan bencana, ketika data dan kinerja layanan yang diperlukan harus dikembalikan sesegera mungkin. Dalam hal ini, kecepatan akses ke cadangan merupakan indikator yang sangat penting.
• Komposisi informasi yang disalin. Cadangan biasanya hanya berisi data pengguna dan bisnis untuk periode yang ditentukan. Salinan pemulihan bencana berisi, selain data ini, baik gambar sistem atau salinan pengaturan sistem operasi dan perangkat lunak aplikasi dan informasi pemulihan lainnya.

Terkadang dimungkinkan untuk menggabungkan tugas-tugas ini. Misalnya, satu set "snapshot" penuh bulanan dari server file tahunan, ditambah perubahan yang dibuat selama seminggu. True Image cocok sebagai alat untuk membuat cadangan semacam itu.

Yang paling penting adalah memahami dengan jelas untuk apa reservasi itu. Biarkan saya memberi Anda sebuah contoh: server SQL kritis gagal karena kegagalan array disk. Kami memiliki stok yang tepat Perangkat keras, jadi solusi untuk masalah itu hanya mengembalikan perangkat lunak dan data. Manajemen perusahaan mengajukan pertanyaan yang dapat dimengerti: "Kapan itu akan berhasil?" - dan sangat terkejut mengetahui bahwa pemulihan akan memakan waktu hingga empat jam. Faktanya adalah bahwa sepanjang masa pakai server, hanya basis data yang dicadangkan secara teratur tanpa memperhitungkan kebutuhan untuk memulihkan server itu sendiri dengan semua pengaturan, termasuk perangkat lunak DBMS itu sendiri. Sederhananya, pahlawan kita hanya menyimpan database, dan mereka melupakan sistemnya.

Saya akan memberi Anda contoh lain. Sepanjang karirnya, profesional muda ini membuat satu salinan file server yang menjalankan Windows Server 2003 menggunakan program ntbackup, termasuk data dan Status Sistem dalam folder bersama di komputer lain. Karena kurangnya ruang disk, salinan ini terus-menerus ditimpa. Beberapa waktu kemudian, dia diminta untuk mengembalikan versi sebelumnya dari laporan multi-halaman yang rusak saat disimpan. Jelas bahwa, karena tidak memiliki riwayat arsip dengan Shadow Copy dimatikan, dia tidak dapat memenuhi permintaan ini.

Berikut ini adalah: Anda perlu menggunakan kedua jenis cadangan: baik untuk pemulihan bencana maupun untuk penyimpanan arsip. Pada saat yang sama, perlu untuk menentukan daftar sumber daya yang akan disalin, waktu untuk melaksanakan tugas, dan juga di mana, bagaimana dan untuk berapa lama salinan cadangan akan disimpan.

Dengan sejumlah kecil data dan infrastruktur TI yang tidak terlalu kompleks, Anda dapat mencoba menggabungkan kedua tugas ini menjadi satu, misalnya, melakukan pencadangan penuh setiap hari untuk semua partisi disk dan database. Tetapi tetap lebih baik untuk membedakan antara dua tujuan dan memilih cara yang tepat untuk masing-masing tujuan tersebut. Oleh karena itu, alat yang berbeda digunakan untuk setiap tugas, meskipun ada solusi universal, seperti paket Acronis True Image atau program ntbackup

Jelas bahwa ketika menentukan tujuan dan sasaran pencadangan, serta solusi untuk implementasi, perlu untuk melanjutkan dari persyaratan bisnis.

Saat menerapkan tugas pemulihan bencana, Anda dapat menggunakan strategi yang berbeda.

Dalam beberapa kasus, perlu untuk mengembalikan sistem secara langsung ke "bare metal" (logam telanjang). Ini dapat dilakukan, misalnya, menggunakan program Acronis True Image yang disertakan dengan modul Pemulihan Universal. Dalam hal ini, konfigurasi server dapat dikembalikan ke layanan dalam waktu yang sangat singkat. Misalnya, partisi dengan sistem operasi 20 GB cukup realistis untuk diangkat dari salinan cadangan dalam delapan menit (asalkan salinan arsip tersedia melalui jaringan 1 GB / dtk).

Dalam pilihan lain, lebih bijaksana untuk hanya "mengembalikan" pengaturan ke sistem yang baru diinstal, seperti menyalin file konfigurasi dari folder /etc dan lain-lain pada sistem mirip UNIX (di Windows, ini kira-kira sesuai dengan menyalin dan memulihkan Status Sistem). Tentu saja, dengan pendekatan ini, server akan dioperasikan tidak lebih awal dari sistem operasi diinstal dan pengaturan yang diperlukan dipulihkan, yang akan memakan waktu lebih lama. jangka panjang. Tetapi bagaimanapun juga, keputusan apa yang menjadi Disaster Recovery berasal dari kebutuhan bisnis dan kendala sumber daya.

Perbedaan mendasar antara sistem redundansi cadangan dan redundansi

Ini adalah pertanyaan menarik lainnya yang ingin saya sentuh. Sistem redundansi perangkat keras yang berlebihan mengacu pada pengenalan beberapa redundansi ke dalam perangkat keras untuk mempertahankan pengoperasian jika terjadi kegagalan mendadak salah satu komponen. Contoh sempurna dalam hal ini adalah array RAID (Redundant Array of Independent Disks). Jika terjadi kegagalan disk tunggal, kehilangan informasi dapat dihindari dan penggantian yang aman dapat dilakukan, menghemat data karena organisasi khusus dari larik disk itu sendiri (baca selengkapnya tentang RAID di).

Saya telah mendengar ungkapan: "Kami memiliki peralatan yang sangat andal, ada array RAID di mana-mana, jadi kami tidak memerlukan cadangan." Ya, tentu saja, array RAID yang sama akan menyimpan data dari kehancuran jika satu hard drive gagal. Tapi itu dari korupsi data virus komputer atau itu tidak akan menyelamatkan dari tindakan pengguna yang tidak kompeten. Itu tidak akan menyimpan RAID bahkan jika sistem file macet sebagai akibat dari reboot yang tidak sah.

Saya akan memberikan satu contoh. Ada kasus ketika peristiwa berkembang sesuai dengan skenario berikut: ketika disk gagal, data dipulihkan karena mekanisme redundansi, khususnya, dengan bantuan penyimpanan checksum. Pada saat yang sama, ada penurunan kinerja yang signifikan, server membeku, kontrol hampir hilang. Administrator sistem, tidak melihat jalan keluar lain, me-reboot server dengan restart dingin (dengan kata lain, klik "RESET"). Sebagai akibat dari kelebihan beban hidup seperti itu, terjadi kesalahan sistem file. Hal terbaik yang dapat diharapkan dalam kasus ini adalah operasi pemeriksa disk yang lama untuk memulihkan integritas sistem file. Dalam kasus terburuk, Anda harus mengucapkan selamat tinggal pada berkas sistem dan bingung dengan pertanyaan di mana, bagaimana dan dalam jangka waktu berapa Anda dapat memulihkan data dan kinerja server.

Anda tidak akan dapat menghindari pencadangan bahkan dengan arsitektur berkerumun. Sebuah cluster failover, pada kenyataannya, membuat layanan yang dipercayakan kepadanya bekerja jika salah satu server gagal. Dalam kasus masalah di atas seperti, serangan virus atau kerusakan data karena "faktor manusia" yang terkenal, tidak ada cluster yang akan disimpan.

Satu-satunya hal yang dapat bertindak sebagai pengganti cadangan yang lebih rendah untuk Pemulihan Bencana adalah adanya server cadangan cermin dengan replikasi data yang konstan dari server utama ke server cadangan (sesuai dengan prinsip Utama Siaga). Dalam hal ini, jika server utama gagal, tugasnya akan diambil alih oleh server cadangan, dan Anda bahkan tidak perlu mentransfer data. Tetapi sistem seperti itu cukup mahal dan memakan waktu untuk diatur. Jangan lupa tentang perlunya replikasi konstan.

Menjadi jelas bahwa solusi seperti itu hemat biaya hanya dalam kasus layanan kritis dengan persyaratan tinggi untuk toleransi kesalahan dan waktu pemulihan minimal. Sebagai aturan, skema semacam itu digunakan di organisasi yang sangat besar dengan perputaran uang komoditas yang tinggi. Dan skema ini adalah pengganti yang lebih rendah untuk cadangan, karena bagaimanapun, jika data rusak oleh virus komputer, tindakan pengguna yang tidak kompeten, atau pekerjaan yang salah aplikasi, data, dan perangkat lunak di kedua server mungkin terpengaruh.

Dan, tentu saja, tidak ada sistem redundansi yang akan menyelesaikan masalah pemeliharaan arsip data untuk jangka waktu tertentu.

Konsep "jendela cadangan"

Melakukan pencadangan memberi beban berat pada server yang berlebihan. Hal ini terutama berlaku untuk subsistem disk dan koneksi jaringan. Dalam beberapa kasus, ketika proses penyalinan sudah cukup prioritas utama, ini dapat menyebabkan tidak tersedianya layanan tertentu. Selain itu, menyalin data pada saat perubahan dikaitkan dengan kesulitan yang signifikan. Tentu saja, ada cara teknis untuk menghindari masalah sambil mempertahankan integritas data dalam kasus ini, tetapi jika memungkinkan, penyalinan dengan cepat sebaiknya dihindari.

Jalan keluar ketika memecahkan masalah yang dijelaskan di atas menyarankan dirinya sendiri: untuk menunda peluncuran proses pembuatan salinan ke periode waktu yang tidak aktif, ketika pengaruh timbal balik dari cadangan dan sistem kerja lainnya akan minimal. Jangka waktu ini disebut "jendela cadangan". Misalnya, untuk organisasi yang mengerjakan rumus 8x5 (lima jam kerja delapan jam seminggu), "jendela" seperti itu biasanya adalah akhir pekan dan jam malam.

Untuk sistem yang bekerja menurut rumus 24x7 (24 jam sehari sepanjang minggu), waktu aktivitas minimum digunakan sebagai periode ketika tidak ada beban tinggi di server.

Jenis cadangan

Untuk menghindari biaya material yang tidak perlu saat mengatur pencadangan, dan juga, jika mungkin, untuk tidak melampaui jendela pencadangan, beberapa teknologi pencadangan telah dikembangkan, yang digunakan tergantung pada situasi tertentu.

Cadangan penuh (atau Cadangan penuh)

Ini adalah metode utama dan mendasar untuk membuat cadangan, di mana array data yang dipilih disalin secara keseluruhan. Ini adalah jenis cadangan yang paling lengkap dan andal, meskipun paling mahal. Jika perlu untuk menyimpan beberapa salinan data, total volume yang disimpan akan meningkat sebanding dengan jumlahnya. Untuk mencegah pemborosan seperti itu, algoritma kompresi digunakan, serta kombinasi metode ini dengan jenis cadangan lainnya: inkremental atau diferensial. Dan, tentu saja, cadangan lengkap sangat diperlukan ketika Anda perlu menyiapkan cadangan untuk pemulihan sistem cepat dari awal.

Salinan tambahan

Tidak seperti full backup, dalam hal ini, tidak semua data (file, sektor, dll) disalin, tetapi hanya yang telah diubah sejak backup terakhir. Untuk mengetahui waktu penyalinan dapat digunakan berbagai metode, misalnya, pada sistem yang menjalankan sistem operasi keluarga Windows, atribut file yang sesuai (bit arsip) digunakan, yang ditetapkan ketika file telah dimodifikasi dan disetel ulang oleh program pencadangan. Sistem lain mungkin menggunakan tanggal modifikasi file. Jelas bahwa skema yang menggunakan jenis cadangan ini akan lebih rendah jika pencadangan penuh tidak dilakukan dari waktu ke waktu. Dengan pemulihan sistem penuh, Anda perlu memulihkan dari salinan terakhir yang dibuat oleh Cadangan penuh, dan kemudian secara bergantian "menggulung" data dari salinan tambahan sesuai urutan pembuatannya.

Untuk apa jenis salinan ini digunakan? Dalam hal membuat salinan arsip, perlu untuk mengurangi volume yang dikonsumsi pada perangkat penyimpanan (misalnya, untuk mengurangi jumlah media pita yang digunakan). Ini juga akan meminimalkan waktu yang diperlukan untuk menyelesaikan tugas pencadangan, yang bisa sangat penting ketika Anda harus bekerja dalam jadwal 24x7 yang sibuk atau mengunduh informasi dalam jumlah besar.

Penyalinan bertahap memiliki satu nuansa yang perlu Anda ketahui. Pemulihan sedikit demi sedikit mengembalikan hak file yang dihapus untuk masa pemulihan. Saya akan memberi Anda sebuah contoh. Misalnya, pencadangan penuh dilakukan pada akhir pekan, dan pencadangan inkremental pada hari kerja. Pengguna membuat file pada hari Senin, mengubahnya pada hari Selasa, menamainya pada hari Rabu, menghapusnya pada hari Kamis. Jadi, dengan pemulihan data bertahap berurutan untuk periode mingguan, kami akan mendapatkan dua file: dengan nama lama pada hari Selasa sebelum penggantian nama, dan dengan nama baru yang dibuat pada hari Rabu. Ini terjadi karena dalam salinan tambahan yang berbeda disimpan versi yang berbeda dari file yang sama, dan akhirnya semua varian akan dipulihkan. Oleh karena itu, ketika memulihkan data secara berurutan dari arsip "sebagaimana adanya", masuk akal untuk memesan lebih banyak ruang disk sehingga file yang dihapus juga dapat ditampung.

Cadangan diferensial

Ini berbeda dari inkremental dalam data yang disalin dari saat terakhir dari Full backup. Dalam hal ini, data ditempatkan dalam arsip secara akrual. Dalam sistem keluarga Windows, efek ini dicapai dengan fakta bahwa bit arsip tidak disetel ulang selama penyalinan diferensial, sehingga data yang diubah masuk ke salinan arsip hingga salinan penuh menyetel bit arsip ke nol.

Karena setiap salinan baru yang dibuat dengan cara ini berisi data dari salinan sebelumnya, akan lebih mudah untuk memulihkan data secara lengkap pada saat bencana. Ini hanya membutuhkan dua salinan: salinan lengkap dan salinan diferensial terakhir, sehingga Anda dapat menghidupkan kembali data lebih cepat daripada menggulirkan semua peningkatan secara bertahap. Selain itu, jenis penyalinan ini terhindar dari fitur penyalinan tambahan di atas, ketika, dengan pemulihan penuh, file lama, seperti burung Phoenix, dilahirkan kembali dari abu. Ada lebih sedikit kebingungan.

Tetapi penyalinan diferensial secara signifikan lebih rendah daripada penyalinan tambahan dalam menghemat ruang yang diperlukan. Karena setiap salinan baru menyimpan data dari salinan sebelumnya, jumlah total data yang dicadangkan dapat dibandingkan dengan salinan lengkap. Dan, tentu saja, ketika merencanakan jadwal (dan menghitung apakah proses pencadangan akan sesuai dengan jendela waktu), Anda perlu memperhitungkan waktu untuk membuat salinan diferensial terakhir yang paling tebal.

Topologi Cadangan

Mari kita lihat apa itu skema pencadangan.

skema terdesentralisasi

Inti dari skema ini adalah berbagi jaringan (lihat Gambar 1). Misalnya, folder bersama atau server FTP. Serangkaian program cadangan juga diperlukan, dari waktu ke waktu mengunggah informasi dari server dan stasiun kerja, serta objek jaringan lainnya (misalnya, file konfigurasi dari router) ke sumber daya ini. Program-program ini diinstal pada setiap server dan bekerja secara independen satu sama lain. Keuntungan yang tidak diragukan adalah kemudahan implementasi skema ini dan biayanya yang rendah. Alat biasa yang dibangun ke dalam sistem operasi, atau perangkat lunak seperti DBMS, cocok sebagai program penyalinan. Misalnya, ini bisa berupa program ntbackup untuk keluarga Windows, program tar untuk sistem operasi mirip UNIX, atau sekumpulan skrip yang berisi perintah server SQL bawaan untuk membuang basis data ke dalam berkas cadangan. Kelebihan lainnya adalah kemampuan untuk menggunakan berbagai program dan sistem, selama semuanya dapat mengakses sumber daya target untuk menyimpan cadangan.

Kelemahannya adalah lambatnya skema ini. Karena program diinstal secara independen satu sama lain, Anda harus mengonfigurasinya satu per satu. Cukup sulit untuk memperhitungkan kekhasan jadwal dan mendistribusikan interval waktu untuk menghindari perebutan sumber daya target. Pemantauan juga sulit, proses penyalinan dari setiap server harus dipantau secara terpisah dari yang lain, yang pada gilirannya dapat menyebabkan biaya tenaga kerja yang tinggi.

Oleh karena itu, skema ini digunakan dalam jaringan kecil, serta dalam situasi di mana tidak mungkin untuk mengatur skema cadangan terpusat dengan alat yang tersedia. Lagi Detil Deskripsi skema dan organisasi praktis ini dapat ditemukan di .

Cadangan Terpusat

Berbeda dengan skema sebelumnya, kasus ini menggunakan model hierarkis yang jelas yang bekerja berdasarkan prinsip "client-server". Dalam versi klasik, program agen khusus diinstal pada setiap komputer, dan modul server dari paket perangkat lunak diinstal pada server pusat. Sistem ini juga memiliki konsol manajemen server khusus. Skema kontrol terlihat seperti ini: dari konsol kami membuat tugas untuk menyalin, memulihkan, mengumpulkan informasi tentang sistem, diagnostik, dan sebagainya, dan server memberi agen instruksi yang diperlukan untuk melakukan operasi ini.

Sebagian besar sistem pencadangan populer bekerja berdasarkan prinsip ini, seperti Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula, dan lainnya (lihat Gambar 2).

Selain berbagai agen untuk sebagian besar sistem operasi, ada pengembangan untuk membuat cadangan basis data populer dan sistem perusahaan, misalnya untuk MS SQL Server, MS Exchange, Oracle Database dan sebagainya.

Untuk perusahaan yang sangat kecil, dalam beberapa kasus, Anda dapat mencoba versi sederhana dari skema cadangan terpusat tanpa menggunakan program agen (lihat Gambar 3). Juga, skema ini dapat digunakan jika agen khusus tidak diterapkan untuk perangkat lunak cadangan yang digunakan. Sebagai gantinya, modul server akan menggunakan layanan dan layanan yang sudah ada sebelumnya. Misalnya, "mengambil" data dari yang disembunyikan folder bersama di server Windows atau menyalin file menggunakan protokol SSH dari server yang menjalankan sistem UNIX. Skema ini memiliki batasan yang sangat signifikan terkait dengan masalah penyimpanan file yang dibuka untuk penulisan. Sebagai akibat dari tindakan tersebut, file yang terbuka akan dilewati dan tidak disertakan dalam cadangan, atau disalin dengan kesalahan. Ada berbagai solusi untuk masalah ini, seperti menjalankan kembali pekerjaan untuk hanya menyalin file yang dibuka sebelumnya, tetapi tidak ada yang dapat diandalkan. Oleh karena itu, skema seperti itu hanya cocok untuk digunakan dalam situasi tertentu. Misalnya, dalam organisasi kecil yang bekerja dalam mode 5x8, dengan karyawan disiplin yang menyimpan perubahan dan menutup file sebelum meninggalkan rumah. Untuk mengatur skema terpusat yang terpotong, beroperasi secara eksklusif di Lingkungan Windows, ntbackup bekerja dengan baik. Jika Anda perlu menggunakan skema serupa di lingkungan yang heterogen atau secara eksklusif di antara komputer UNIX, saya sarankan untuk melihat ke PC Cadangan (lihat).

Gambar 4. Skema pencadangan campuran

Apa itu di luar situs?

Di dunia kita yang bergejolak dan berubah, peristiwa dapat terjadi yang dapat menyebabkan konsekuensi yang tidak menyenangkan bagi infrastruktur TI dan bisnis secara keseluruhan. Misalnya, kebakaran di gedung. Atau kerusakan pada baterai pemanas sentral di ruang server. Atau pencurian peralatan dan komponen yang dangkal. Salah satu metode untuk menghindari kehilangan informasi dalam situasi seperti itu adalah dengan menyimpan salinan cadangan di tempat yang jauh dari lokasi utama peralatan server. Pada saat yang sama, perlu untuk menyediakan cara cepat akses ke data yang diperlukan untuk pemulihan. Metode yang dijelaskan disebut off-site (dengan kata lain, menyimpan salinan di luar perusahaan). Pada dasarnya, dua metode pengorganisasian proses ini digunakan.

Menulis data ke media yang dapat dipindahkan dan gerakan fisiknya. Dalam hal ini, perlu untuk menjaga sarana pengiriman kembali media dengan cepat jika terjadi kegagalan. Misalnya, simpan di gedung terdekat. Keuntungan dari metode ini adalah kemampuan untuk mengatur proses ini tanpa kesulitan. Kelemahannya adalah rumitnya pengembalian media dan sangat perlunya transfer informasi untuk penyimpanan, serta risiko kerusakan media selama transportasi.

Salin data ke lokasi lain melalui tautan jaringan. Misalnya, menggunakan terowongan VPN melalui Internet. Keuntungan dalam hal ini adalah tidak perlu membawa media dengan informasi ke suatu tempat, minusnya adalah perlu menggunakan saluran yang cukup lebar (biasanya ini sangat mahal) dan melindungi data yang ditransmisikan (misalnya, menggunakan VPN yang sama). Kesulitan mentransfer data dalam jumlah besar dapat sangat dikurangi dengan menggunakan algoritma kompresi atau teknologi deduplikasi.

Secara terpisah, perlu disebutkan langkah-langkah keamanan dalam organisasi penyimpanan data. Pertama-tama, perlu diperhatikan bahwa pembawa data berada di ruang yang aman, dan tentang langkah-langkah yang mencegah orang yang tidak berwenang membaca data. Misalnya, menggunakan sistem enkripsi, membuat perjanjian non-disclosure, dan sebagainya. Jika media yang dapat dipindahkan terlibat, data di dalamnya juga harus dienkripsi. Sistem penandaan yang digunakan seharusnya tidak membantu penyerang dalam analisis data. Penting untuk menggunakan skema penomoran tanpa wajah untuk menandai pembawa nama-nama file yang ditransfer. Saat mentransfer data melalui jaringan, perlu (seperti yang telah disebutkan di atas) untuk menggunakan metode transfer data yang aman, misalnya, terowongan VPN.

Kami telah menganalisis poin-poin utama saat mengatur cadangan. Pada bagian selanjutnya, rekomendasi metodologi akan dipertimbangkan dan contoh praktis untuk membuat sistem cadangan yang efisien.

1. Deskripsi cadangan Sistem Windows, termasuk Status Sistem - http://www.datamills.com/Tutorials/systemstate/tutorial.htm .
2. Deskripsi Salinan Bayangan - http://ru.wikipedia.org/wiki/Shadow_Copy .
3. Situs web resmi Acronis - http://www.acronis.ru/enterprise/products .
4. Deskripsi ntbackup adalah http://en.wikipedia.org/wiki/NTBackup.
5. Berezhnoy A. Mengoptimalkan kerja MS SQL Server. // Administrator sistem, No. 1, 2008 - Hal. 14-22 ().
6. Berezhnoy A. Kami mengatur sistem cadangan untuk kantor kecil dan menengah. // Administrator sistem, No. 6, 2009 - Hal. 14-23 ().
7. Markelov A. Linux menjaga Windows. Tinjauan dan pemasangan sistem pencadangan BackupPC. // Administrator sistem, No. 9, 2004 - Hal. 2-6 ().
8. Deskripsi VPN - http://ru.wikipedia.org/wiki/VPN.
9. Deduplikasi Data - http://en.wikipedia.org/wiki/Data_deduplication .

dalam kontak dengan

Hampir semua pelanggan kami yang telah menerapkan sistem cadangan (BMS) berpikir bahwa ini menyelesaikan semua masalah mereka. Mereka melakukan segala daya mereka untuk memastikan bahwa semuanya telah dicadangkan dan, jika terjadi kecelakaan, dipulihkan dengan benar. Tetapi sering terjadi seperti ini: perusahaan menghadapi masalah serius, dan sistem pencadangan tradisional tidak memungkinkan Anda untuk memulihkan dalam waktu yang dianggap perusahaan sebagai target. Faktanya, SLA, yang harus dipatuhi oleh sistem cadangan, tidak terpenuhi. Sayangnya, selama pekerjaan kami, kami telah mengumpulkan banyak contoh menyedihkan yang mengkonfirmasi hal ini. Di bawah ini kami menyajikan dua kasus dan memberikan saran tentang cara teknis apa yang akan mengurangi waktu pemulihan. Saat memilih kasus, kami berfokus pada contoh yang terkait dengan database, tempat informasi paling penting bisnis disimpan.

Tantangan Ritel

Pelanggan: perusahaan asuransi besar.

Deskripsi singkat tentang penyebab crash: kesalahan personel, pemasangan patch yang salah di Oracle.

Deskripsi masalah

Kita berbicara tentang perusahaan besar yang memiliki departemen TI yang matang dan cukup berinvestasi dalam peralatan dan stafnya. Cukuplah untuk mengatakan bahwa Oracle DBMS berjalan pada dua Oracle Exadata, didistribusikan melalui dua situs teknologi, dengan solusi DR yang dikembangkan dengan baik dan sistem cadangan yang disesuaikan.

Suatu hari yang menyedihkan, diputuskan untuk menginstal patch pada Oracle DBMS. Sayangnya, insinyur tidak membaca instruksi sampai akhir: "Apa, saya tidak akan menginstal tambalan tanpa selembar kertas ?!" - dan melakukannya dengan salah. Kesalahan diketahui beberapa jam kemudian, ketika DBMS mulai berperilaku aneh dan melaporkannya di log. Kemudian insinyur memutuskan untuk memutar kembali. Tindakan ini akhirnya melumpuhkan kedua contoh database (semua perubahan berhasil direplikasi ke Standby) dan merusak semua data.

Perusahaan dibiarkan tanpa aset informasi utamanya - database tempat semua proses bisnis bekerja. Bisnis praktis berhenti.

Larutan

Pelanggan telah memutuskan untuk memulihkan dari cadangan. Pada saat itu, memulihkan database 5 TB (sekarang ~ 15 TB) membutuhkan - perhatian! - lebih dari 30 jam! Secara total, setelah 1,5 hari pangkalan dipulihkan sehari sebelum kecelakaan. Tapi ada lebih banyak data! Segala sesuatu yang lain dipulihkan oleh pemrogram dan staf dari sistem perusahaan lain, dari dokumentasi utama (formulir aplikasi, salinan, pindaian). Butuh 1,5 hari kerja keras lagi.

Total

2 sistem Oracle Exadata High-End, Oracle Standby, sistem backup yang berfungsi dan 3!!! hari waktu henti total pada pemasangan yang salah tambalan. Apakah ini diperbolehkan oleh kebijakan perusahaan? Tentu saja tidak.

Masalah utama: kurangnya alat pemulihan cepat untuk kesalahan logis.

Bagaimana Anda bisa menghindari?

Untuk mengurangi konsekuensi dari kecelakaan seperti itu, Anda perlu bergerak ke dua arah. Di satu sisi, untuk membuat cadangan lebih sering, dan di sisi lain, untuk dapat memulihkan dengan cepat. Produk berikut mungkin membantu:

Oracle FlashBack- teknologi yang memungkinkan Anda untuk tidak hanya "menggulung" data baru ke sistem cadangan Oracle, tetapi juga kembalikan ke transaksi yang diinginkan. Dengan skema seperti itu, dimungkinkan untuk memutar kembali sistem sebelum masalah dengan patch dimulai, yang akan sangat memudahkan pemulihan data.

Teknologi cuplikan. Snapshot memungkinkan Anda mencadangkan dan memulihkan data dalam hitungan detik. Pada saat yang sama, efeknya kecil pada kinerja, dan memungkinkan untuk mengambil foto cukup sering (misalnya, sekali dalam satu jam). Dengan demikian, dimungkinkan untuk memutar kembali satu jam dan memulihkan hanya satu jam data yang hilang.

Perlindungan Data Berkelanjutan- perlindungan data terus menerus. Ini adalah perangkat atau perangkat lunak berpemilik yang memungkinkan Anda mencatat semua catatan dengan kemampuan untuk memutar kembali ke titik waktu mana pun. Bekerja mirip dengan Oracle FlashBack, tetapi untuk data apa pun.

Kasus: Kegagalan perangkat keras

Pelanggan: Layanan federal di salah satu entitas konstituen Federasi Rusia

Deskripsi singkat tentang penyebab crash: kesalahan perangkat keras di dalam array disk.

Deskripsi masalah

Kali ini perusahaan memiliki infrastruktur TI yang sedikit kurang berkembang, tetapi lebih umum dengan pelanggan kami: array disk tingkat menengah, Oracle DBMS, Standby tidak digunakan.

Seperti yang sering terjadi, pada hari Jumat, ketika semua orang dengan senang hati pulang, perangkat keras array gagal. Karena bug di firmware, ketika disk gagal, array mengubah data menjadi berantakan. Dari sini, database layanan tingkat federal berhenti bekerja. Selama lebih dari sehari, pelanggan menunggu solusi dari vendor penyimpanan. Setelah menganalisis semua log, vendor memberikan kesimpulannya: data hilang!

Larutan

Pelanggan telah memutuskan untuk memulihkan dari cadangan. Proses ini memakan waktu sekitar satu hari, terlepas dari semua trik dan penyetelan kinerja (basisnya cukup besar). Saat database sedang dipulihkan, salinan cadangan log hilang (Periode Retensi disetel terlalu pendek, SRK menghapusnya sendiri).

Lebih jauh - lebih dalam. Perusahaan, seperti banyak perusahaan lain, di beberapa titik menggunakan operasi yang tidak dicatat di Oracle, yang sangat meningkatkan kinerja, tetapi tidak meninggalkan kesempatan untuk memulihkan, kecuali dari cadangan. Artinya, harus dilakukan segera setelah sesi operasi. Secara alami, selama bertahun-tahun, layanan operasi melupakan hal ini. Dengan demikian, sebagian data benar-benar hilang.

Butuh beberapa hari lagi untuk sepenuhnya memulihkan layanan infrastruktur - tidak ada salinan cadangan sistem operasi, binari, konfigurasi, dll.

Semua informasi yang hilang dikumpulkan dari dokumen utama (basis data pihak ketiga, dokumen kertas, data di komputer teller), yang memakan waktu 3 hari lagi. Beberapa dokumen mungkin tidak pernah dipulihkan.

Total

Masalah array menyebabkan kehilangan data dan waktu henti selama sekitar satu minggu! Dalam kondisi modern, hal ini dapat menyebabkan kebangkrutan perusahaan.

Masalah utama:

• RMS tidak diatur dengan benar, pemulihan percobaan tidak dilakukan.
• Tidak ada cara pemulihan yang cepat jika terjadi kecelakaan dan tidak ada sistem yang berlebihan.
• Tidak ada rencana DR yang jelas.

Bagaimana ini bisa dihindari:

• Gunakan Oracle Standby yang terletak di array lain. Ini akan memungkinkan untuk waktu yang singkat untuk beralih ke instance data yang sedang berjalan.
• Oracle ZDLRA akan memungkinkan untuk memulihkan database pada peralatan cadangan dalam waktu yang jauh lebih singkat.
• Perencanaan proses pencadangan dan pemulihan yang tepat akan menghindari kerugian besar seperti itu dan pulih dalam waktu kurang dari sehari.

Kesimpulan. Dari contoh di atas, dapat dilihat bahwa sistem cadangan telah diinstal dan dikonfigurasi, tetapi meskipun demikian, sistem tersebut tidak dapat pulih dalam jangka waktu yang ditentukan dalam SLA.

Masalah utama sistem cadangan

Berdasarkan pengalaman kami, kami memutuskan untuk menyoroti sejumlah masalah yang, menurut pendapat kami, harus diperhatikan oleh pembaca secara khusus.

Kecepatan pencadangan dan pemulihan selanjutnya

pada saat ini kecepatan backup berbanding lurus dengan jumlah data, sementara semua pelanggan kami memiliki pertumbuhan data tahunan minimal 30%. Dalam 3-4 tahun, data setidaknya berlipat ganda, tetapi untuk beberapa perusahaan angka ini bahkan lebih tinggi, sementara pada saat yang sama kecepatan pencadangan tidak berubah sama sekali. Di sini kita dapat membuat kesimpulan sederhana bahwa istilah-istilah itu dan SLA yang relevan 3-4 tahun yang lalu sekarang perlu setidaknya dua kali lipat. Pada saat yang sama, kebutuhan bisnis untuk pemulihan data (RPO / RTO) terus berkembang.

Secara bertahap, semua proses bisnis perusahaan dialihkan ke TI dan dokumen utama kertas (salinan dan dokumen asli, aplikasi, pindaian, dll.) sekarat. Semuanya berputar di dalam sistem TI, dan kehilangan data, pada kenyataannya, adalah hilangnya segalanya. TI tidak lagi berhak melakukan kesalahan. Dalam kasus yang kami kutip, sepanjang waktu data tidak tersedia karena berbagai keadaan, perusahaan tidak dapat berfungsi. Ini menyebabkan kerugian langsung, ketika tidak mungkin untuk melakukan proses bisnis utama organisasi, dan yang implisit, misalnya, reputasi, yang tidak mudah diukur dalam istilah moneter, tetapi di masa depan dapat menyebabkan tidak sedikit merugikan perusahaan.

Pada gambar Saya mencerminkan pengamatan saya tentang waktu pemulihan (RTO). Seiring pertumbuhan data, waktu pemulihan yang sebenarnya pasti akan meningkat, sementara persyaratan SLA hanya akan menjadi lebih ketat. Titik pada grafik di mana waktu sebenarnya sama dengan waktu yang dibutuhkan telah dilewati untuk sebagian besar pelanggan.

Ketergantungan waktu pemulihan pada jumlah data

Pemulihan granularitas rendah

Faktanya, sebagian besar kesalahan disebabkan oleh hilangnya beberapa bagian data. Pada saat yang sama, alat pencadangan tradisional memungkinkan Anda memulihkan data langsung dari cadangan, tetapi lebih sering Anda harus memulihkan seluruh sistem. Jika database Anda adalah 15 TB, Anda akan menghabiskan beberapa hari untuk itu. Kami tidak mengetahui pelanggan yang memiliki persyaratan RTO (Recovery Time Objective) 2 hari. Dalam praktik kami, tidak ada contoh seperti itu ketika klien akan berkata: "Teman-teman, itu normal untuk pulih selama 2 hari, saya akan bersabar," jika administrator secara tidak sengaja menghapus beberapa baris dari database. Masalah yang cukup umum yang dihadapi pelanggan kami adalah bagaimana mengisolasi sebagian kecil data dari cadangan tanpa memulihkannya sendiri (dan tidak menghabiskan beberapa hari untuk itu).

RPO berlebihan (Tujuan Titik Pemulihan)

Di dunia di mana catatan kertas telah hilang dan semuanya disimpan dalam sistem TI, data dibuat setiap detik yang ingin kami lindungi segera - pada saat yang sama ketika data itu dibuat. Tetapi dengan bantuan sistem pencadangan klasik, ini tidak dapat dilakukan. Untuk setiap bagian data, ada periode waktu tertentu yang panjang di mana data ini ada di seluruh dunia dalam satu salinan. Pelanggan kami ingin melindungi data secara terus-menerus, sejak data tersebut muncul. Saat memutuskan untuk memulihkan dari cadangan, kemungkinan besar Anda harus memulihkan sehari yang lalu, kemudian data untuk hari itu perlu diperoleh dari tempat lain. Sebagai aturan, ini kerja panjang administrator, memakan waktu beberapa hari. Dalam skenario paling negatif, ini bisa berubah menjadi kerugian informasi penting. Tentu saja, pertanyaannya tidak terbatas pada cadangan, ini menyangkut pembangunan sistem TI secara keseluruhan, tetapi topik RMS dalam hal ini sangat penting, tidak dapat diabaikan.

Bug tersembunyi

Sayangnya, masih belum ada opsi murah dan cepat untuk memeriksa seberapa baik pencadangan dilakukan. Tentu saja, ini dapat dilakukan dengan pemulihan uji berkala, tetapi ini adalah operasi yang sangat mahal dalam hal upaya manusia dan sumber daya TI. Ini adalah pekerjaan tim yang terpisah pada perangkat keras yang terpisah.

Sayangnya, sebagian besar klien kami tidak. Sering terjadi bahwa setiap orang membuat salinan cadangan, tetapi pada saat pemulihan, ternyata itu tidak dapat dilakukan - mereka tidak dipulihkan, meskipun operasi RMS secara lahiriah benar. Hal ini terjadi karena berbagai alasan. Dan cara terbaik untuk menunjukkan ini adalah dengan sebuah contoh. Salah satu pelanggan kami menggunakan sistem SAP dengan database Oracle. Pencadangan dilakukan oleh alat SAP bawaan dengan bantuan salah satu vendor terbesar SRK.

2 kebijakan pencadangan yang berbeda dikonfigurasi: salah satunya berbasis file - menyalin data sistem operasi dan pengaturan perangkat lunak, dan yang kedua - database itu sendiri. Karena mereka diarahkan ke sistem yang sama, daftar pengecualian dibuat di mana database dimasukkan. Kebijakan file memperhitungkan daftar ini dan tidak mencadangkan direktori tempat database berada. Karena kekhasan arsitektur RMS, kebijakan reservasi database mengabaikan daftar pengecualian dan menyalin data yang diperlukan dengan benar.

Dalam salah satu rilis perangkat lunak, vendor ini memperbaiki "bug" ini, sejak hari itu, kedua kebijakan mulai memperhitungkan daftar pengecualian dan mem-bypass database. Selain itu, ini tidak mempengaruhi kesalahan dalam perangkat lunak RMS dengan cara apa pun, karena berfungsi normal: semua data yang tidak ditentukan dalam daftar dicadangkan secara normal. Sistem melaporkan kemudahan servisnya.

Jadi, semuanya bekerja selama lebih dari enam bulan. Sampai Anda perlu pulih ...

Pendekatan non-sistematis

Masalah penting adalah pendekatan non-sistematis untuk masalah backup. RMS secara historis dibangun baik oleh perusahaan itu sendiri atau oleh integrator yang terlibat. Pada saat konstruksi, tentu memenuhi semua persyaratan dan menjalankan fungsinya sepenuhnya. Seiring waktu, lanskap TI perusahaan telah berubah. Pada saat yang sama, sistem cadangan hanya menyesuaikannya dengan sistem yang dikembangkan, dan paling sering tidak ada pendekatan sistematis yang akan mempertimbangkan pentingnya menjaga sistem tetap sesuai dengan indikator awal pada semua tahap selanjutnya yang diamati. Saat membangun RMS di organisasi Anda, ingatlah bahwa ini hanya bagian dari strategi perlindungan data Anda.

Kami telah menyajikan beberapa studi kasus yang menunjukkan bahwa pendekatan perlindungan data harus komprehensif. Sayangnya, SRC hanyalah parasut cadangan, bukan peluru perak, jadi ketika Anda mulai membuatnya, Anda perlu memahami dengan jelas tempat yang akan digunakan dalam strategi perlindungan data global.

Untuk memeriksa seberapa sistematis Anda telah mendekati masalah membangun RMS, jawablah beberapa pertanyaan sederhana:

• Apakah Anda memiliki model risiko bawaan, di mana tempat IBS terdaftar?
• Dari kegagalan apa IBS melindungi Anda?
• Bagaimana Anda melindungi diri Anda dari risiko lain (ini mungkin bukan hanya solusi teknis, tetapi juga tindakan kompensasi lainnya)?
• Apakah Anda yakin bahwa sistem akan pulih dalam jangka waktu yang ditentukan?
• Sudahkah Anda menguji ini dalam praktik?

Larutan

Berdasarkan pengalaman kami sendiri dan pengalaman pelanggan kami, kami telah mencoba mengembangkan pendekatan yang memungkinkan kami untuk memecahkan atau secara signifikan mengurangi konsekuensi dari masalah ini. Inti dari pendekatan kami:

Pertama, Anda perlu memisahkan kecepatan pencadangan dan pemulihan dari volume sistem. Produsen sistem penyimpanan, perangkat lunak aplikasi, dan RMS menawarkan beberapa alat yang dapat digunakan untuk mengatasi masalah ini. Di bawah ini saya akan menjelaskan yang paling menjanjikan dari mereka.

Snapshot memungkinkan Anda mencadangkan dan memulihkan data dalam hitungan detik tanpa berdampak pada kinerja. Ini dilakukan melalui array, dan pada saat yang sama dapat dikendalikan oleh SRC, menjadi bagian dari kebijakannya. Pencadangan dan pemulihan seperti itu benar-benar membutuhkan waktu beberapa detik, yang membedakan teknologi ini dari sistem klasik dengan media yang dapat dialihfungsikan.

Solusi lain bisa dengan menggunakan berbagai alat aplikasi, seperti Oracle Standby, DB2 HADR, MS SQL Always On. Semua alat ini memungkinkan Anda untuk memiliki salinan kerja dari sistem yang produktif, dipisahkan dari aslinya, yang dapat digunakan secara instan. Ini memungkinkan Anda untuk mulai bekerja segera setelah kegagalan.

Yang kedua adalah memberikan kesempatan untuk memulihkan hanya data yang diperlukan. Pendekatan kami memperhitungkan bahwa ketika memulihkan sebagian data, kami tidak perlu menyalin seluruh sistem, kami dapat memulihkan data yang kami butuhkan saat ini. Ini dicapai dengan kemampuan untuk menyebarkan atau menggunakan sistem yang sudah digunakan yang berisi data ini dengan cepat. Sama seperti dalam kasus pertama, snapshot memungkinkan Anda untuk memecahkan masalah ini (Anda dapat dengan cepat membuka snapshot ke server tetangga dan mengeluarkan bagian data yang diperlukan). Ini juga mencakup teknologi perlindungan data berkelanjutan, misalnya, Oracle Standby dengan Flashback, solusi perlindungan data berkelanjutan (CDP). Mereka memungkinkan Anda untuk dengan cepat menyebarkan salinan data Anda yang berfungsi ke momen yang tepat waktu.

Ketika Anda perlu mendapatkan satu blok logis, misalnya, baris atau tabel database, alat ini sangat memudahkan tugas, memungkinkan Anda untuk memulihkan bagian data yang diperlukan tanpa mengembalikan seluruh salinan.

Yang ketiga adalah untuk mengurangi kesenjangan antara tampilan data dan perlindungannya. Hal ini dapat dicapai dengan beberapa cara, berdasarkan kekhususan kasus tertentu dan tingkat kepentingan data.

Misalnya, untuk sistem yang kurang kritis, interval waktu pencadangan dapat dikurangi menjadi beberapa jam. Dalam hal ini, kami menggunakan snapshot. Mereka dapat berfungsi sebagai titik pemulihan, yang dapat dilakukan satu jam sekali. Beberapa array modern mengatasi proses ini dengan cukup baik dan dapat menyimpan cukup banyak sejumlah besar snapshot sistem. Ini adalah jalan keluar yang bagus dari situasi di mana Anda perlu mundur beberapa saat.

Untuk sistem yang paling kritis, mungkin tidak ada interval waktu sama sekali - data harus dilindungi terus menerus. Ada beberapa solusi dari kelas ini, misalnya Oracle Standby dengan FlashBack, yang memungkinkan Anda untuk memutar kembali database beberapa waktu lalu dengan mencatat semua perubahan. Anda juga dapat menggunakan Oracle ZDLRA HSS, yang hampir secara sinkron menerima semua perubahan dalam database, atau sistem perangkat lunak dan perangkat keras tujuan umum seperti EMC RecoverPoint, perangkat lunak Vision Solutions Double-Take. Mereka juga mencatat semua perubahan dan memungkinkan Anda untuk memulihkan ke titik mana pun dalam interval waktu.

Ketika berbicara tentang inovasi dalam sistem pencadangan dan pemulihan, tidak ada salahnya untuk menyebutkan Oracle Zero Data Loss Recovery Appliance (ZDLRA). Kompleks perangkat lunak dan perangkat keras dari keluarga Sistem Rekayasa Oracle ini menyediakan kemampuan untuk mencadangkan dan memulihkan Database Oracle dengan cepat dari platform apa pun dan Edisi apa pun (Perusahaan dan Standar). ZDLRA didasarkan pada basis data cadangan virtual (Virtual Full Backup), diperoleh berdasarkan cadangan penuh pertama dan log perubahan berikutnya. Karena pencadangan virtual ini, Anda dapat memulihkan basis data ke titik waktu mana pun jauh lebih cepat dibandingkan dengan penggunaan klasik RMS menurut skema "pencadangan penuh seminggu sekali, inkremental sekali sehari". Kita dapat mengatakan bahwa ZDLRA melanjutkan arahan yang diberikan oleh Oracle Exadata. Di Exadata, karena Perangkat Lunak khusus, sistem penyimpanan inovatif diimplementasikan, dioptimalkan untuk tugas-tugas Database Oracle. Dan di ZDLRA ada Software khusus yang mengoptimalkan backup Oracle Database.

Sekarang kita hanya berbicara tentang pemulihan operasional. Jika terjadi bencana besar atau kebutuhan untuk memulihkan lebih banyak waktu, pencadangan reguler tetap menjadi alat yang sangat diperlukan. Namun dalam kondisi saat ini, parasut ini hanya cadangan, dibuka pada saat-saat terakhir.

Yang keempat adalah pengurangan kesalahan laten. Hanya ada satu cara untuk memastikan bahwa cadangan berfungsi dengan benar - mencoba memulihkannya. Ini adalah metode yang paling benar dan jarang digunakan oleh pelanggan kami.

Tapi kami menawarkan jalan keluar dari situasi ini. Pertama, memiliki instance sistem yang mudah dipulihkan. Sekali lagi ini adalah cerita tentang sistem snapshot dan standby yang dapat dengan cepat digunakan dan diuji. Ini akan memakan waktu dan usaha yang jauh lebih sedikit daripada "melepas" seluruh cadangan. Tentu saja, ini tidak selalu membantu, tetapi meninggalkan sedikit harapan bahwa dalam keadaan darurat akan mungkin untuk memulihkan data setidaknya dengan cara ini.

Kedua, beberapa SRK memungkinkan Anda melakukan pengujian otomatis. Pada waktu tertentu, sesuai jadwal, Anda dapat berlari mesin virtual dalam lingkungan yang terisolasi dan menurut algoritme yang telah ditentukan sebelumnya, periksa apakah data benar-benar telah dipulihkan, apakah aplikasi tersedia, apakah konsisten, apakah ia merespons permintaan yang diperlukan. Dengan cara ini, administrator dapat diselamatkan dari pekerjaan rutin yang panjang.

Kelima - transparansi sistem cadangan. Pendekatan terintegrasi yang dijelaskan melibatkan pembangunan sistem yang kompleks menggunakan berbagai teknologi dari produsen yang berbeda. Tugas membuat sistem ini benar-benar bisa diterapkan, meletakkan di dalamnya kemungkinan perubahan dan penskalaan lebih lanjut, bukanlah hal yang sepele, dan dapat diselesaikan dengan dua cara:

• Cara pertama - asalkan pelanggan cukup kompeten dan ingin menjalankan sistem ini. Di sini kami, sebagai integrator, membantu membangun semua proses yang diperlukan, membuat kerangka peraturan, mengembangkan semua instruksi dan rencana yang diperlukan sehingga departemen TI pelanggan dapat lebih mandiri mengembangkan dan mengoperasikan sistem di cara yang benar. Dan kemudian mentransfer semua dasar peraturan dan tugas praktis ini kepada pelanggan dalam bentuk sistem kerja proses bisnis.

• Cara kedua, ketika pelanggan tidak yakin bahwa ia akan dapat mempertahankan sistem RMS terus-menerus dalam keadaan tempur, jalan keluarnya adalah dengan mengalihkan sistem ke outsourcing parsial atau penuh. Dan kami memiliki klien yang berhasil menggunakan layanan ini, terus meningkatkan persyaratan SLA dan skala keterlibatan kami sebagai outsourcing TI.

Sayangnya, belum ada resep universal yang akan memecahkan masalah pemulihan data dalam kondisi pertumbuhan konstan dan kerumitan sistem saat ini. Hanya kombinasi dari solusi di atas dan pendekatan sistematis yang akan memungkinkan perusahaan untuk memulihkan data dalam jangka waktu yang dibutuhkan oleh bisnis.