Memulihkan cadangan yang dipertahankan dalam jangka panjang

Anda dapat memulihkan cadangan yang dipertahankan dalam jangka panjang langsung dari bucket Cloud Storage menggunakan utilitas mandiri, sehingga memastikan akses data meskipun tanpa appliance Backup and DR yang aktif.

Dokumen ini menjelaskan cara menggunakan utilitas pemulihan mandiri ini untuk menemukan, memverifikasi, memasang, dan memulihkan image cadangan Backup and DR OnVault dan Compute Engine.

Ringkasan

Cadangan yang dipertahankan dalam jangka panjang disimpan di bucket Cloud Storage menggunakan kebijakan OnVault untuk kepatuhan dan pengarsipan. Untuk memastikan aksesibilitas data secara terpisah dari infrastruktur pencadangan, Anda dapat menggunakan utilitas pemulihan mandiri untuk menemukan, memverifikasi, dan memulihkan data ini langsung dari bucket penyimpanan. Hal ini penting untuk skenario disaster recovery atau penghapusan ketika appliance pencadangan/pemulihan asal mungkin tidak tersedia.

Sebelum memulai

Sebelum Anda mulai memulihkan cadangan yang dipertahankan dalam jangka panjang, selesaikan bagian berikut.

Mendapatkan peran yang diperlukan

Untuk mendapatkan izin yang diperlukan guna memulihkan cadangan yang dipertahankan dalam jangka panjang, minta administrator Anda untuk memberi Anda peran IAM Backup and DR Cloud Storage Operator (roles/backupdr.cloudStorageOperator) di bucket Cloud Storage target. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Prasyarat lainnya

Sebelum memulihkan cadangan yang dipertahankan dalam jangka panjang, pastikan Anda memenuhi prasyarat berikut:

  1. Sebelum Anda memulai pemulihan, pastikan data Anda tersedia di penyimpanan OnVault. Verifikasi cadangan yang ada di kumpulan perangkat pencadangan/pemulihan, lalu migrasikan ke OnVault dengan menetapkan kebijakan perlindungan OnVault yang relevan.

  2. Untuk skenario pemulihan yang melibatkan snapshot Persistent Disk (Persistent Disk), verifikasi bahwa semua metadata cadangan direplikasi ke bucket Cloud Storage target. Utilitas pemulihan bergantung pada metadata ini untuk mengatalogkan dan memproses gambar snapshot. Untuk memfasilitasi transfer data dan mengonfirmasi bahwa metadata ada di bucket Cloud Storage, hubungi Cloud Customer Care.

  3. Pastikan sistem host tempat Anda menjalankan alat ini memenuhi persyaratan berikut:

    • gcloud CLI: Diinstal dan dapat diakses di variabel lingkungan PATH Anda (khususnya gcloud storage).
    • Autentikasi: Dikonfigurasi dengan kredensial aktif dengan menjalankan gcloud auth login, atau menggunakan Kredensial Default Aplikasi (ADC) atau kunci akun layanan.

  4. Identifikasi dan simpan daftar nama bucket Cloud Storage dan Google Cloud project ID yang sesuai untuk digunakan dengan utilitas pemulihan.

Men-deploy utilitas pemulihan

Konfigurasi instance VM untuk berfungsi sebagai proxy pemulihan atau sebagai host aplikasi tujuan, lalu deploy alat pemulihan mandiri.

Menemukan peralatan, host, dan gambar

Utilitas pemulihan mandiri menerima sepasang nilai bucket dan project (--bucket dan --project) untuk perintah. Utilitas ini mendukung operasi berikut:

  • Mencantumkan aplikasi
  • Mencantumkan cadangan
  • Masa berlaku cadangan berakhir
  • Memasang gambar cadangan
  • Lepaskan gambar cadangan

Pasang image cadangan

Untuk melakukan pemasangan pemulihan, Anda harus mengidentifikasi nama image cadangan terlebih dahulu.

Buat daftar cadangan yang tersedia untuk mengidentifikasi nama image cadangan:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

Kemudian, untuk melakukan pemasangan pemulihan non-interaktif, gunakan perintah yang mirip dengan contoh berikut untuk memasang image cadangan yang dipilih langsung ke proxy pemulihan yang ditetapkan atau server database target:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

Ganti kode berikut:

  • BUCKET_NAME: nama bucket Cloud Storage.
  • PROJECT_ID: Google Cloud Project ID Anda.
  • APPLIANCE_NAME: nama atau ID perangkat pencadangan/pemulihan.
  • HOST_NAME: nama host atau ID host sumber.
  • APPLICATION_NAME: nama atau ID aplikasi yang dilindungi.
  • IMAGE_NAME: nama image cadangan aktif yang akan dipasang.
  • MOUNT_POINT: (Opsional) jalur direktori lokal tempat cadangan dipasang. Defaultnya adalah /tmp/recovery_folder.

Setelah ekstraksi selesai, Anda dapat melihat data yang dicadangkan di direktori pemasangan.

Memulihkan aplikasi

Untuk mengakses file database mentah, buka MOUNT_POINT/restored_data/. Pilih jalur pemulihan untuk jenis beban kerja dan konfigurasi pemasangan Anda:

Microsoft SQL

  1. Temukan file: identifikasi file database .mdf dan .ldf utama di direktori db_volume/.
  2. Lampiran langsung (host yang sama): hentikan instance database target. Buka SQL Server Management Studio, pilih Attach Database, lalu tentukan jalur file yang mengarah ke file data dan log di direktori pemasangan pemulihan.
  3. Salin dan lampirkan (host berbeda): hentikan instance database target. Transfer file .mdf dan .ldf ke drive penyimpanan lokal server target, lalu lampirkan menggunakan SQL Server Management Studio.

Oracle

  1. Menemukan file: utilitas secara otomatis mendeteksi file init.ora atau spfile dan file data .dbf sambil mengaktifkan cadangan database RMAN dan grup volume Archive log.
  2. Pulihkan database: nonaktifkan instance Oracle target atau mulai dalam mode NOMOUNT. Perbarui parameter inisialisasi (seperti file kontrol) agar mengarah ke file .dbf yang di-mount untuk validasi langsung, atau salin file .dbf ke penyimpanan lokal atau penyimpanan Pengelolaan Penyimpanan Otomatis (ASM) untuk pemulihan permanen.
  3. Buka database: bawa instance ke status MOUNT, terapkan log pemulihan yang diperlukan dari grup volume TransactionLog yang di-mount, lalu buka database.

VM VMware Engine

Selain pemulihan aplikasi database, perlindungan virtual machine Google Cloud VMware Engine (VMware Engine) mencakup seluruh konfigurasi hardware bersama dengan cakupan disk virtual.

  1. Pasang dan temukan file: pasang gambar cadangan seperti yang dijelaskan dalam Memasang gambar cadangan. Utilitas membuat disk virtual jarang (vol00.raw) dalam jalur pemasangan utama. Kemudian, disk dilampirkan untuk mengekspos sistem file sistem operasi tamu di direktori db_volume/, sementara metadata konfigurasi VMware (termasuk .ovf, .vmx, dan Catalog.xml) diatur dalam folder log_files/.
  2. Memulihkan VM secara langsung: nonaktifkan VM target untuk mengamankan disk dasarnya untuk parsing manifes. Proses pekerja membaca blok data dari penyimpanan lokal, menuliskannya ke VMDK menggunakan library VMware Virtual Disk Development Kit (VDDK), lalu otomatis memulai ulang VM.

Snapshot PD Compute Engine

Berbeda dengan cadangan OnVault yang di-mount sebagai sistem file lokal, snapshot Persistent Disk Compute Engine dipulihkan dengan menginisialisasi persistent disk baru dan melampirkannya langsung ke instance Compute Engine target.

  1. Identifikasi target pencadangan dan metadata: pastikan file katalog metadata snapshot Persistent Disk (pdsnapshot_catalog.json) ada di bucket Cloud Storage Anda. Gunakan utilitas pengelola persistent disk untuk meninjau pencadangan yang tersedia yang tercantum dalam katalog dan pilih IMAGE ID tertentu yang ditujukan untuk pemulihan.
  2. Memulihkan dan melampirkan volume: gunakan perintah attach untuk mengotomatiskan pembuatan persistent disk dari snapshot cadangan. Satu tindakan ini menangani pembuatan dan koneksi semua volume yang relevan ke virtual machine tujuan Anda.
  3. Pasang perangkat di tingkat sistem operasi: setelah pemasangan selesai, hubungkan ke instance Compute Engine target untuk mengidentifikasi perangkat blok yang baru dipetakan menggunakan alat seperti lsblk. Pasang sistem file secara manual untuk mengakses data yang dipulihkan atau memulai proses pemulihan aplikasi.

SAP HANA PD

Tidak seperti pencadangan OnVault, yang dipasang langsung sebagai sistem file lokal, pemulihan snapshot Persistent Disk SAP HANA melibatkan penyediaan persistent disk baru dan melampirkannya ke instance Compute Engine target.

  1. Verifikasi metadata dan temukan image cadangan: pastikan file katalog metadata snapshot Persistent Disk tersedia di bucket Cloud Storage. Gunakan alat pengelola persistent disk untuk memeriksa cadangan yang dikatalogkan dan memilih IMAGE ID yang diperlukan untuk pemulihan.
  2. Menyediakan disk dan melampirkan volume: jalankan perintah attach untuk mengotomatiskan pembuatan persistent disk dari snapshot cadangan yang dipilih. Langkah ini membuat semua volume yang diperlukan dan melampirkannya ke virtual machine target dalam satu operasi.
  3. Pasang perangkat di tingkat sistem operasi: setelah disk terpasang, hubungkan ke VM SAP HANA tujuan dan periksa perangkat blok yang baru ditetapkan menggunakan alat seperti lsblk. Pasang sistem file secara manual untuk mengakses data yang dipulihkan atau memulai pemulihan tingkat aplikasi.
  4. Memulihkan SAP HANA: setelah memasang volume data, log, dan log arsip SAP HANA, mulai database sistem (termasuk pemulihan point-in-time jika diperlukan), diikuti dengan pemulihan dan inisialisasi database tenant.

IBM Db2 PD

Berbeda dengan pencadangan OnVault, yang dipasang langsung sebagai sistem file lokal, memulihkan snapshot Persistent Disk IBM Db2 memerlukan penyediaan persistent disk baru dan melampirkannya ke instance Compute Engine tujuan.

  1. Temukan image cadangan dan validasi metadata: pastikan file katalog metadata snapshot Persistent Disk ada di bucket Cloud Storage yang ditentukan. Gunakan alat pengelola persistent disk untuk memeriksa cadangan yang dikatalogkan guna mengidentifikasi dan memilih IMAGE ID target yang diperlukan untuk pemulihan.
  2. Hubungkan volume dan sediakan disk: jalankan perintah attach untuk membuat persistent disk secara otomatis dari snapshot pencadangan yang ditentukan. Satu langkah ini menyediakan semua volume yang diperlukan dan melampirkannya langsung ke mesin virtual target.
  3. Pasang sistem file sistem operasi: setelah memasang disk, hubungkan ke VM IBM Db2 target untuk mengidentifikasi perangkat blok yang baru dipetakan menggunakan alat seperti lsblk. Pasang sistem file secara manual untuk mengakses data yang dipulihkan atau lanjutkan pemulihan aplikasi.
  4. Memulihkan database aplikasi: setelah Anda memasang volume data Db2, log transaksi, dan log arsip, katalogkan setiap instance database Db2, lakukan pemulihan database sesuai kebutuhan, dan aktifkan database.

MySQL/MariaDB

  1. Temukan file: temukan direktori data utama di db_volume/, yang berisi database pengguna, skema sistem, dan tablespace InnoDB.

  2. Memulihkan database: menghentikan layanan MySQL atau MariaDB yang aktif. Untuk menguji secara langsung, sesuaikan entri datadir di my.cnf untuk menargetkan folder pemasangan pemulihan. Untuk pemulihan permanen, salin file database ke penyimpanan lokal (seperti /var/lib/mysql/) dan pastikan kepemilikan dan izin sistem file yang benar.

  3. Aktifkan dan pulihkan: mulai ulang layanan database. Jika log transaksi biner ada, lakukan pemulihan point-in-time dengan menggunakan utilitas mysqlbinlog.

PostgreSQL

  1. Temukan file: di direktori db_volume/, identifikasi aset PGDATA, termasuk database inti (base/, global/, dan pg_wal/) serta file konfigurasi postgresql.conf.

  2. Memulihkan database: nonaktifkan instance PostgreSQL tujuan. Untuk validasi langsung dari pemasangan, arahkan variabel lingkungan data_directory atau PGDATA ke jalur pemulihan. Untuk memulihkan secara permanen, transfer struktur direktori lengkap ke penyimpanan lokal host target.

  3. Buka database: mulai ulang layanan untuk mengaktifkan instance. Jika pemulihan point-in-time diperlukan, terapkan log WAL yang diarsipkan dari folder log_files/ dengan menentukan file recovery.conf atau mengonfigurasi restore_command dalam postgresql.conf (untuk PostgreSQL 12 dan yang lebih baru), lalu aktifkan database.

SAP ASE

  1. Temukan file: identifikasi perangkat utama, bersama dengan database pengguna dan perangkat log tertentu, yang berada dalam folder db_volume/ yang ter-mount.

  2. Pulihkan database: nonaktifkan instance SAP ASE tujuan. Untuk pemasangan langsung, perbarui konfigurasi RUN_server untuk mengalihkan parameter perangkat utama (seperti -d) ke jalur pemulihan. Atau, transfer semua aset perangkat ke lokasi penyimpanan permanennya.

  3. Open database: memulai proses server data SAP ASE. Jika log transaksi ada, jalankan operasi LOAD TRAN untuk melakukan pemulihan point-in-time sebelum mengaktifkan database.

SAP MaxDB

  1. Temukan volume: buka jalur pemasangan db_volume/ untuk menemukan file data dan log SAP MaxDB utama.

  2. Memulihkan atau mengalihkan konfigurasi: hentikan proses SAP MaxDB tujuan. Gunakan Pengelola Database (dbmcli) untuk memperbarui parameter seperti DataVolumeName agar mengarah ke pemasangan pemulihan, atau salin file langsung ke penyimpanan lokal untuk pemulihan penuh.

  3. Mulai dan aktifkan: mulai instance database dan tetapkan status operasionalnya ke ONLINE menggunakan Pengelola Database.

SAP IQ

  1. Temukan file: buka direktori db_volume/ untuk mengidentifikasi penyimpanan utama SAP IQ, penyimpanan katalog (.db), dan semua aset penyimpanan sementara terkait.

  2. Memulihkan database: nonaktifkan instance SAP IQ tujuan. Untuk melakukan validasi langsung dari pemasangan pemulihan, ubah parameter startup untuk mereferensikan file katalog yang terpasang. Untuk pemulihan permanen, transfer semua volume toko ke penyimpanan lokal sambil memverifikasi bahwa kepemilikan dan izin sistem file yang sesuai dipertahankan.

  3. Buka database: jalankan utilitas start_iq untuk mengaktifkan instance dan memverifikasi integritas data.

LVM/dump IBM Db2

  1. Temukan file: buka jalur pemasangan db_volume/ dan log_files/. Berdasarkan metode perlindungan, identifikasi volume data dan log LVM atau aset gambar cadangan tertentu untuk pemulihan berbasis dump.
  2. Memulihkan database (LVM): nonaktifkan instance Db2 tujuan. Transfer data database dan volume log transaksi aktif dari pemasangan pemulihan ke penyimpanan lokal target, dengan memastikan kepemilikan sistem file yang benar untuk pengguna dan grup Db2.
  3. Memulihkan database (penuh dan inkremental berbasis dump): hentikan koneksi aktif dan hapus database target jika ada. Gunakan alat db2ckrst dengan stempel waktu pencadangan tertentu untuk mengatalogkan urutan inkremental yang diperlukan. Jalankan operasi RESTORE untuk setiap gambar dalam urutan yang ditentukan.
  4. Open database: memulai instance Db2. Jika database tetap dalam status tertunda atau memerlukan pemulihan point-in-time, terapkan log transaksi menggunakan utilitas db2 rollforward untuk menyelesaikan pemulihan dan mengaktifkan instance.

Membersihkan resource

Setelah menyalin atau melepaskan semua file database yang diperlukan dari mesin database, lepaskan volume aktif dengan aman, lepaskan perangkat loop terkait, dan hapus direktori penyiapan lokal untuk menghindari kunci residual atau referensi yang tidak memiliki induk.

Untuk melepas volume dan membersihkan direktori pemulihan, jalankan perintah berikut:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

Ganti kode berikut:

  • MOUNT_POINT: jalur direktori lokal tempat cadangan dipasang, seperti /tmp/recovery_folder.

Langkah berikutnya