Mengonfigurasi pencadangan yang konsisten dengan aplikasi

Dokumen ini menunjukkan cara mengonfigurasi alur kerja pencadangan terjadwal yang konsisten dengan aplikasi dan pemulihan point-in-time (PITR) untuk database yang dikelola sendiri yang berjalan di instance virtual machine (VM) Linux Compute Engine.

Saat Anda mencadangkan beban kerja database stateful—seperti IBM Db2, SAP HANA, MySQL, atau PostgreSQL—snapshot standar yang konsisten terhadap error yang diambil oleh Backup and DR dapat merekam database saat transaksi masih berlangsung. Transaksi yang tidak lengkap ini dapat merusak data, membuat tabel dalam status yang tidak konsisten, dan memerlukan rutinitas perbaikan database yang panjang saat pemulihan setelah terjadi error. Cadangan yang konsisten dengan aplikasi menyelesaikan masalah ini dengan berintegrasi dengan agen tamu VM untuk menghentikan sementara database dan secara opsional membekukan sistem file sebelum membuat snapshot.

Sebelum memulai

Selesaikan tugas berikut sebelum mengonfigurasi pencadangan yang konsisten dengan aplikasi.

Peran yang diperlukan

Untuk mendapatkan izin yang diperlukan untuk mengonfigurasi pencadangan yang konsisten dengan aplikasi, minta administrator Anda untuk memberi Anda peran IAM berikut di project Anda:

• Untuk mengonfigurasi dan mengelola rencana pencadangan: Pengguna Pencadangan Backup and DR (roles/backupdr.backupUser)
• Untuk mengelola instance Compute Engine: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)
• Untuk mengakses secret Secret Manager dari skrip: Secret Manager Secret Accessor (roles/secretmanager.secretAccessor)

Untuk mengetahui informasi selengkapnya tentang pemberian 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

1. Di konsol Google Cloud , pada halaman pemilih project, pilih atau buat Google Cloud project.

   Buka pemilih project

2. Verifikasi bahwa penagihan diaktifkan untuk project Anda.

   Pelajari cara mengonfirmasi bahwa penagihan diaktifkan

3. Aktifkan Backup and DR API dan Secret Manager API.

   Aktifkan API

4. Pastikan data database dan file log Anda disimpan di Persistent Disk standar. Volume Google Cloud Hyperdisk tidak mendukung operasi guest-flush.

5. Jika Anda berencana mengonfigurasi pemulihan point-in-time, konfigurasi database Anda untuk mengarsipkan log transaksi dan redo ke Persistent Disk khusus yang terpisah—misalnya, dipasang di /db2/ACT/log_archive.

Menggunakan framework penghapusan tamu bring-your-own-script (BYOS)

Backup dan DR menggunakan framework flush tamu Bring-Your-Own-Script (BYOS) untuk mengistirahatkan database Anda sebelum snapshot diambil. Lingkungan tamu bergantung pada dua skrip yang berada di direktori /etc/google/snapshots/ pada instance VM Linux Anda:

• Skrip pra-snapshot (/etc/google/snapshots/pre.sh): Dieksekusi sebelum snapshot diambil. Skrip ini harus menghentikan operasi database dan secara opsional dapat membekukan sistem file.
• Skrip pasca-snapshot (/etc/google/snapshots/post.sh): Dieksekusi setelah snapshot diambil. Skrip ini harus secara opsional mencairkan sistem file dan melanjutkan operasi database.

Untuk mempelajari lebih lanjut template skrip khusus database, lihat Meninjau contoh skrip menurut jenis database.

Opsional: Membekukan dan mencairkan sistem file

Membekukan sistem file menggunakan utilitas Linux standar fsfreeze bersifat opsional dan tidak wajib. Mengistirahatkan database Anda memastikan konsistensi transaksi tingkat aplikasi. Namun, jika memerlukan konsistensi tingkat sistem file tambahan, Anda dapat secara opsional menyertakan perintah pembekuan dan pembatalan pembekuan sistem file berikut dalam skrip Anda.

Pastikan skrip pre.sh dan post.sh di VM dikonfigurasi untuk menangani pembekuan sistem file opsional untuk volume log tanpa menangguhkan operasi database.

Menambahkan petunjuk pembekuan sistem file ke pre.sh

Jika Anda memilih untuk membekukan sistem file, tambahkan logika penemuan dan pembekuan berikut di akhir skrip pre.sh setelah menghentikan sementara database:

# Discover local writeable mount points
MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

# FREEZE FILESYSTEMS (Optional)
for mnt in $MOUNT_POINTS; do
    if ! sudo fsfreeze -f "$mnt"; then
        logger "Error: Failed to freeze $mnt. Cleaning up..."
        # Attempt emergency thaw
        for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
        # Add your database-specific resume/cleanup commands here before exiting
        exit 1
    fi
    logger "Filesystem $mnt is frozen."
done

Menambahkan petunjuk pelepasan sistem file ke post.sh

Jika Anda membekukan sistem file di pre.sh, tambahkan logika pencairan berikut di awal skrip post.sh sebelum melanjutkan database:

# Discover local writeable mount points
MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

# UNFREEZE FILESYSTEMS (Optional)
for mnt in $MOUNT_POINTS; do
    sudo fsfreeze -u "$mnt"
    logger "Filesystem $mnt is unfrozen."
done

Mengambil kredensial secara dinamis dengan Secret Manager

Hindari melakukan hardcode pada kredensial atau sandi database statis di dalam skrip shell Anda. Sebagai gantinya, gunakan Secret Manager untuk mengambil kredensial secara dinamis saat runtime. Ganti variabel sandi statis dalam skrip Anda dengan logika berikut:

# Fetch the database password from Secret Manager dynamically
DBPASSWORD=$(gcloud secrets versions access latest \
    --secret="SECRET_NAME" \
    --format='get(payload.data)' | tr -d '\n')

if [ $? -ne 0 ]; then
    logger "Critical Error: Unable to fetch the password from Secret Manager."
    exit 1
fi

Ganti SECRET_NAME dengan nama secret di Secret Manager.

Meninjau skrip contoh menurut jenis database

Contoh berikut memberikan penerapan pre.sh dan post.sh untuk mesin database yang didukung yang berjalan di instance Linux.

Catatan: Untuk beban kerja Microsoft SQL Server, tidak seperti lingkungan Linux yang mengandalkan skrip kustom, Windows memanfaatkan Volume Shadow Copy Service (VSS) bawaannya. Dalam lingkungan Windows, alur kerja guest-flush menggunakan agen VSS Google Cloud untuk berinteraksi dengan layanan sistem Windows. Sebelum snapshot diambil, VSS secara otomatis mengosongkan buffer sistem file dan mengistirahatkan beban kerja SQL Server yang kompatibel, serta melakukan semua data dalam memori ke disk untuk memastikan konsistensi tingkat aplikasi yang kuat. Untuk mengetahui informasi selengkapnya, lihat [Membuat snapshot disk yang konsisten dengan aplikasi Windows](/compute/docs/instances/windows/creating-windows-persistent-disk-snapshot).

IBM Db2

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/pre.sh
 # 1. Define Mount Points for the Database
 MOUNT_POINTS=("DATA_MOUNT_POINT" "LOG_MOUNT_POINT")
 logger "BYOS Framework: Starting pre-snapshot script."

 # 2. QUIESCE DATABASE (Generic Hook)
 # Replace with DB-specific command (e.g., 'db2 set write suspend')
 logger "Suspending Database I/O..."
 # [INSERT DB QUIESCE COMMAND HERE]

 # 3. FREEZE FILESYSTEMS (Optional)
 for mnt in "${MOUNT_POINTS[@]}"; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt."
         # Attempt emergency thaw
         for thaw_mnt in "${MOUNT_POINTS[@]}"; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         # [INSERT DB RESUME COMMAND HERE]
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/post.sh
 MOUNT_POINTS=("DATA_MOUNT_POINT" "LOG_MOUNT_POINT")
 logger "BYOS Framework: Starting post-snapshot script."

 # 1. UNFREEZE FILESYSTEMS (Optional)
 for mnt in "${MOUNT_POINTS[@]}"; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done

 # 2. RESUME DATABASE (Generic Hook)
 # Replace with DB-specific command (e.g., 'db2 set write resume')
 logger "Resuming Database I/O..."
 # [INSERT DB RESUME COMMAND HERE]
 logger "BYOS Framework: Cleanup complete."

Oracle

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 sudo mkdir -p /etc/google/snapshots
 sudo tee /etc/google/snapshots/pre.sh > /dev/null << 'EOF'
 #!/bin/bash
 # Place Oracle (ASM) into hot backup mode before Backup and DR captures disks
 su - oracle -c "sqlplus -s / as sysdba" << 'SQL'
 WHENEVER SQLERROR EXIT FAILURE;
 ALTER DATABASE BEGIN BACKUP;
 EXIT;
 SQL

 if [ $? -ne 0 ]; then
   echo "Error: Failed to place Oracle in backup mode. Aborting snapshot." >&2
   exit 1
 fi
 EOF

 sudo chmod 750 /etc/google/snapshots/pre.sh

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 sudo tee /etc/google/snapshots/post.sh > /dev/null << 'EOF'
 #!/bin/bash
 # Release Oracle from backup mode and archive current redo log to +FRA
 su - oracle -c "sqlplus -s / as sysdba" << 'SQL'
 WHENEVER SQLERROR EXIT FAILURE;
 ALTER DATABASE END BACKUP;
 ALTER SYSTEM ARCHIVE LOG CURRENT;
 EXIT;
 SQL

 if [ $? -ne 0 ]; then
   echo "Warning: Failed to execute ALTER DATABASE END BACKUP." >&2
   exit 1
 fi
 EOF

 sudo chmod 750 /etc/google/snapshots/post.sh

SAP HANA

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/pre.sh

 DISK_ARG="$1"

 # 1. Configuration & Discovery
 DBSID="DBSID"
 DBADM="DBADM"
 ID_FILE="/tmp/hana_snapshot_id_$DBSID"
 HDB_KEY="HDB_KEY"

 if [[ "$DISK_ARG" == "," ]] || [[ "$DISK_ARG" == "1/0" ]] || [[ "$DISK_ARG" == "sda" ]]; then
     # Dynamically discover all local writeable mount points for full VM image consistency
     # Filters out pseudo, temporary, and read-only filesystems
     MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

     logger "SAP HANA Full VM BYOS: Starting pre-snapshot script for $DBSID."

     # 2. QUIESCE DATABASE (Create SAP HANA Snapshot)
     logger "SAP HANA Full VM BYOS: Creating database snapshot..."

     # Determine HANA Version
     # Versions 2.0+ use 'FOR FULL SYSTEM' syntax
     HANAVERSION=$(su - $DBADM -c "HDB version" | grep "version:" | awk '{print $2}' | cut -d'.' -f1)

     if [ "$HANAVERSION" = "1" ]; then
         SQL="BACKUP DATA CREATE SNAPSHOT COMMENT 'SNAPSHOT_$(date +%Y%m%d)'"
     else
         SQL="BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT_$(date +%Y%m%d)'"
     fi

     # Execute the snapshot command via hdbsql
     su - $DBADM -c "hdbsql -j -U $HDB_KEY \"$SQL\""
     if [ $? -ne 0 ]; then
         logger "Error: Failed to create SAP HANA snapshot."
         exit 1
     fi

     # Retrieve the BACKUP_ID for the prepared snapshot
     ID=$(su - $DBADM -c "hdbsql -j -t -U $HDB_KEY \"SELECT BACKUP_ID FROM M_BACKUP_CATALOG WHERE STATE_NAME = 'prepared' ORDER BY SYS_START_TIME DESC\"" | head -n 2 | tr -d '"' | tail -n 1)

     if [ -z "$ID" ]; then
         logger "Error: Could not retrieve BACKUP_ID for prepared snapshot."
         exit 1
     fi

     echo "$ID" > "$ID_FILE"
     logger "SAP HANA Full VM BYOS: Database snapshot prepared with ID $ID."
 fi

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/post.sh

 DISK_ARG="$1"

 # 1. Configuration & Discovery
 DBSID="DBSID"
 DBADM="DBADM"
 ID_FILE="/tmp/hana_snapshot_id_$DBSID"
 HDB_KEY="HDB_KEY"

 if [[ "$DISK_ARG" == "," ]] || [[ "$DISK_ARG" == "1/0" ]] || [[ "$DISK_ARG" == "sda" ]]; then
     # Discover all local writeable mount points to perform unfreeze
     MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

     logger "SAP HANA Full VM BYOS: Starting post-snapshot script for $DBSID."

     # 3. RESUME DATABASE (Close SAP HANA Snapshot)
     if [ -f "$ID_FILE" ]; then
         ID=$(cat "$ID_FILE")
         logger "SAP HANA Full VM BYOS: Closing database snapshot ID $ID..."

         # Determine HANA version for correct syntax
         HANAVERSION=$(su - $DBADM -c "HDB version" | grep "version:" | awk '{print $2}' | cut -d'.' -f1)

         if [ "$HANAVERSION" = "1" ]; then
             SQL="BACKUP DATA CLOSE SNAPSHOT BACKUP_ID $ID SUCCESSFUL 'SNAPSHOT_COMPLETED'"
         else
             SQL="BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID $ID SUCCESSFUL 'SNAPSHOT_COMPLETED'"
         fi

         # Execute the close snapshot command
         RESULT=$(su - $DBADM -c "hdbsql -j -U $HDB_KEY \"$SQL\"")
         if [ $? -ne 0 ]; then
             logger "Error: Failed to close SAP HANA snapshot. $RESULT"
         else
             logger "SAP HANA Full VM BYOS: Database snapshot closed successfully."
         fi

         # Cleanup the temporary ID file
         rm -f "$ID_FILE"
     else
         logger "Error: Snapshot ID file not found. Manual intervention required to close HANA snapshot."
     fi

     logger "SAP HANA Full VM BYOS: Cleanup complete."

 else
     MOUNT_POINTS="/hanabackup"

     for mnt in $MOUNT_POINTS; do
         sudo fsfreeze -u "$mnt"
         logger "Filesystem $mnt is unfrozen."
     done
 fi

Ganti kode berikut:

• DBSID: ID sistem (SID) SAP HANA dalam huruf besar.
• DBADM: pengguna OS administrator SAP HANA (seperti <sid>adm).
• HDB_KEY: kunci userstore SAP HANA yang dikonfigurasi untuk akses database.

SAP ASE

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/pre.sh
 # 1. Configuration
 OSUSER="OS_USER"
 SYB_SERVER="SYB_SERVER_NAME"
 SYB_USER="SYB_USER"
 SYB_PASS="SYB_PASSWORD"
 SYB_DBLIST="DATABASE_LIST"
 TAG_NAME="SNAPSHOT_$(date +%Y%m%d)"
 MANIFEST_DIR="/var/tmp/sybase_manifests" # Directory for manifest files
 # 2. Discovery
 # Dynamically discover local writeable mount points
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "Sybase Full VM BYOS: Starting pre-snapshot script."
 # 3. QUIESCE DATABASE
 mkdir -p "$MANIFEST_DIR"
 chown $OSUSER "$MANIFEST_DIR"

 logger "Sybase Full VM BYOS: Quiescing databases: $SYB_DBLIST..."
 # Command logic from act_sybase_pre.sh
 # We use 'hold' to suspend activity and create the manifest file
 su - $OSUSER -c "isql -U$SYB_USER -P$SYB_PASS -S$SYB_SERVER -X --retserverror" <<EOF
 quiesce database $TAG_NAME hold $SYB_DBLIST for external dump to '$MANIFEST_DIR/manifest_$TAG_NAME.dat' with override
 go
 exit
 EOF
 if [ $? -ne 0 ]; then
     logger "Error: Failed to quiesce Sybase databases."
     exit 1
 fi
 # 4. FREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt."
         # Attempt emergency thaw
         for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         # Release the database quiesce
         su - $OSUSER -c "isql -U$SYB_USER -P$SYB_PASS -S$SYB_SERVER -X" <<EOF
         quiesce database $TAG_NAME release
         go
         exit
 EOF
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/post.sh

 # 1. Configuration
 OSUSER="OS_USER"
 SYB_SERVER="SYB_SERVER_NAME"
 SYB_USER="SYB_USER"
 SYB_PASS="SYB_PASSWORD"
 TAG_NAME="SNAPSHOT_$(date +%Y%m%d)"
 MANIFEST_DIR="/var/tmp/sybase_manifests"

 # 2. Discovery
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "Sybase Full VM BYOS: Starting post-snapshot script."

 # 3. UNFREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done

 # 4. RESUME DATABASE
 logger "Sybase Full VM BYOS: Releasing databases for tag $TAG_NAME..."

 # Command logic from act_sybase_post.sh
 su - $OSUSER -c "isql -U$SYB_USER -P$SYB_PASS -S$SYB_SERVER -X" <<EOF
 use master
 go
 quiesce database $TAG_NAME release
 go
 exit
 EOF

 if [ $? -ne 0 ]; then
     logger "Error: Failed to release Sybase databases."
 else
     logger "Sybase Full VM BYOS: Databases released successfully."
     # Cleanup manifest
     rm -f "$MANIFEST_DIR/manifest_$TAG_NAME.dat"
 fi

 logger "Sybase Full VM BYOS: Cleanup complete."

Ganti kode berikut:

• OS_USER: pengguna sistem operasi yang menjalankan SAP ASE (seperti sybase).
• SYB_SERVER_NAME: nama server SAP ASE.
• SYB_USER: pengguna database dengan izin untuk menghentikan sementara database.
• SYB_PASSWORD: sandi pengguna database (atau ambil secara dinamis dengan Secret Manager).
• DATABASE_LIST: daftar database yang dipisahkan koma untuk diistirahatkan.

SAP IQ

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/pre.sh

 # 1. Configuration
 OSUSER="OS_USER"
 DB_NAME="DB_NAME"
 CONN_STR="uid=DB_USER;pwd=DB_PASSWORD;dbn=$DB_NAME;eng=ENGINE_NAME"
 BKP_DIR="/var/tmp/sybaseiq_bkp"
 FULL_BKP_FILE="$BKP_DIR/FULL_VIR_DEC"

 # 2. Discovery
 # Dynamically discover all local writeable mount points for full VM consistency
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "SybaseIQ Full VM BYOS: Starting pre-snapshot script."

 # 3. QUIESCE DATABASE (Virtual Decoupled Backup)
 mkdir -p "$BKP_DIR"
 chown $OSUSER "$BKP_DIR"

 logger "SybaseIQ Full VM BYOS: Preparing virtual decoupled backup..."

 # Execute the quiesce command logic from act_sybaseiq_pre.sh
 su -m $OSUSER -c "dbisql -nogui -c '$CONN_STR' \"BACKUP DATABASE FULL VIRTUAL DECOUPLED TO '$FULL_BKP_FILE'\""

 if [ $? -ne 0 ]; then
     logger "Error: Failed to freeze (not able to take full_vir_dec backup)."
     exit 1
 fi

 # 4. FREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt."
         # Attempt emergency thaw
         for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         # Cleanup quiesce file as backup is invalid
         rm -f "$FULL_BKP_FILE"
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/post.sh
 # 1. Configuration
 OSUSER="OS_USER"
 DB_NAME="DB_NAME"
 CONN_STR="uid=DB_USER;pwd=DB_PASSWORD;dbn=$DB_NAME;eng=ENGINE_NAME"
 BKP_DIR="/var/tmp/sybaseiq_bkp"
 FULL_BKP_FILE="$BKP_DIR/FULL_VIR_DEC"
 INC_BKP_FILE="$BKP_DIR/INC_BKP"
 # 2. Discovery
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)
 logger "SybaseIQ Full VM BYOS: Starting post-snapshot script."
 # 3. UNFREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done
 # 4. RESUME DATABASE (Post-Snapshot Cleanup)
 logger "SybaseIQ Full VM BYOS: Performing incremental since full backup..."
 # Logic from act_sybaseiq_post.sh to finish the decoupled sequence
 su -m $OSUSER -c "dbisql -nogui -c '$CONN_STR' \"BACKUP DATABASE INCREMENTAL SINCE FULL TO '$INC_BKP_FILE'\""
 if [ $? -ne 0 ]; then
     logger "Error: Failed post-quiesce incremental backup."
 fi
 # Remove temporary files created during quiesce
 rm -f "$FULL_BKP_FILE"*
 logger "SybaseIQ Full VM BYOS: Cleanup complete."

Ganti kode berikut:

• OS_USER: pengguna sistem operasi yang menjalankan SAP IQ (seperti sybiq).
• DB_NAME: nama database SAP IQ.
• DB_USER: pengguna database dengan hak istimewa DBA.
• DB_PASSWORD: sandi pengguna database (atau ambil secara dinamis dengan Secret Manager).
• ENGINE_NAME: nama mesin database SAP IQ.

SAP MaxDB

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/pre.sh

 # 1. Configuration
 DBSID="DBSID"
 OSUSER="OS_USER"
 MAXDB_KEY="-user DBM_USER,DBM_PASSWORD"
 AUTOLOG_TMPLT="LOG_BACKUP"

 # 2. Discovery
 # Dynamically discover all local writeable mount points for full VM consistency
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "MaxDB Full VM BYOS: Starting pre-snapshot script for $DBSID."

 # 3. QUIESCE DATABASE
 # Optional: Trigger a log backup first to ensure point-in-time recovery readiness
 logger "MaxDB Full VM BYOS: Triggering log backup..."
 su -m $OSUSER -c "dbmcli -d $DBSID $MAXDB_KEY -uUTL -c backup_start $AUTOLOG_TMPLT LOG"

 # Suspend logwriter to quiesce the database
 logger "MaxDB Full VM BYOS: Suspending logwriter..."
 su -m $OSUSER -c "dbmcli -d $DBSID $MAXDB_KEY -uUTL -c util_execute suspend logwriter"
 if [ $? -ne 0 ]; then
     logger "Error: Failed to suspend MaxDB logwriter."
     exit 1
 fi

 # 4. FREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt."
         # Attempt emergency thaw
         for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         # Resume the logwriter as the backup is no longer consistent
         su -m $OSUSER -c "dbmcli -d $DBSID $MAXDB_KEY -uUTL -c util_execute resume logwriter"
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/post.sh

 # 1. Configuration
 DBSID="DBSID"
 OSUSER="OS_USER"
 MAXDB_KEY="-user DBM_USER,DBM_PASSWORD"

 # 2. Discovery
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "MaxDB Full VM BYOS: Starting post-snapshot script for $DBSID."

 # 3. UNFREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done

 # 4. RESUME DATABASE
 logger "MaxDB Full VM BYOS: Resuming logwriter..."
 su -m $OSUSER -c "dbmcli -d $DBSID $MAXDB_KEY -uUTL -c util_execute resume logwriter"
 if [ $? -ne 0 ]; then
     logger "Error: Failed to resume MaxDB logwriter."
 else
     logger "MaxDB Full VM BYOS: Logwriter resumed successfully."
 fi

 logger "MaxDB Full VM BYOS: Cleanup complete."

Ganti kode berikut:

• DBSID: ID sistem (SID) SAP MaxDB dalam huruf besar.
• OS_USER: pengguna sistem operasi yang menjalankan MaxDB (seperti sdba).
• DBM_USER: pengguna Pengelola Database (DBM).
• DBM_PASSWORD: sandi pengguna DBM (atau gunakan kunci DBM tersimpan: -k KEY_NAME).

PostgreSQL

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # 1. Configuration
 OSUSER="OS_USER"
 PG_HOME="PG_HOME"
 DBUSER="DB_USER"
 PORT=PORT_NUMBER
 DBNAME="DB_NAME"
 FIFO="/tmp/pg_backup_fifo_$PORT"
 PID_FILE="/tmp/pg_backup_pid_$PORT"
 ACT_JOBNAME="SNAPSHOT_$(date +%Y%m%d%H%M%S)"

 # 2. Discovery
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)
 export PATH=$PG_HOME/bin:$PATH

 logger "PostgreSQL Full VM BYOS: Starting pre-snapshot script."

 # 3. QUIESCE DATABASE (Session-Bound)
 rm -f "$FIFO"
 mkfifo "$FIFO"
 chown "$OSUSER" "$FIFO"

 su "$OSUSER" -c "psql -p $PORT -U $DBUSER -d $DBNAME -f $FIFO" > /tmp/pg_backup_output.log 2>&1 &
 echo $! > "$PID_FILE"

 psql_version=$(su "$OSUSER" -c "psql --version" | awk '{print $3}' | cut -d'.' -f1)
 if [ "$psql_version" -ge 15 ]; then
     CMD="SELECT pg_backup_start('$ACT_JOBNAME');"
 else
     CMD="SELECT pg_start_backup('$ACT_JOBNAME');"
 fi

 echo "$CMD" > "$FIFO"
 sleep 2

 # 4. FREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt. Cleaning up..."
         for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         echo "SELECT pg_backup_stop(); exit;" > "$FIFO"
         rm -f "$FIFO" "$PID_FILE"
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 PORT=PORT_NUMBER
 FIFO="/tmp/pg_backup_fifo_$PORT"
 PID_FILE="/tmp/pg_backup_pid_$PORT"

 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)
 logger "PostgreSQL Full VM BYOS: Starting post-snapshot script."

 # 1. UNFREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done

 # 2. RESUME DATABASE (Close Session)
 if [ -p "$FIFO" ]; then
     logger "PostgreSQL Full VM BYOS: Closing backup session via FIFO..."
     echo "SELECT pg_backup_stop(); SELECT pg_stop_backup(); exit;" > "$FIFO"
     if [ -f "$PID_FILE" ]; then
         wait "$(cat "$PID_FILE")" 2>/dev/null
     fi
     rm -f "$FIFO" "$PID_FILE"
     logger "PostgreSQL Full VM BYOS: Database session closed."
 else
     logger "Error: FIFO not found. Session may have terminated unexpectedly."
 fi
 logger "PostgreSQL Full VM BYOS: Cleanup complete."

Ganti kode berikut:

• OS_USER: pengguna sistem operasi yang menjalankan PostgreSQL (seperti postgres).
• PG_HOME: jalur ke direktori penginstalan PostgreSQL.
• DB_USER: pengguna database PostgreSQL dengan hak istimewa superuser.
• PORT_NUMBER: nomor port yang digunakan PostgreSQL untuk memproses (default: 5432).
• DB_NAME: nama database yang akan dihubungkan.

MySQL

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # 1. Configuration
 DBUSER="DB_USER"
 DBPASSWORD="DB_PASSWORD"
 PORTNO=PORT_NUMBER
 SOCKET_FILE="/var/run/mysqld/mysqld.sock"
 MYSQL_PATH="/usr/bin/mysql"
 FIFO="/tmp/mysql_backup_fifo_$PORTNO"
 PID_FILE="/tmp/mysql_backup_pid_$PORTNO"

 # 2. Discovery
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "MySQL Full VM BYOS: Starting pre-snapshot script."

 # 3. QUIESCE DATABASE (Session-Bound Lock)
 rm -f "$FIFO"
 mkfifo "$FIFO"

 $MYSQL_PATH -u"$DBUSER" -p"$DBPASSWORD" -S"$SOCKET_FILE" -P"$PORTNO" < "$FIFO" > /tmp/mysql_backup_output.log 2>&1 &
 echo $! > "$PID_FILE"

 logger "MySQL Full VM BYOS: Issuing FLUSH TABLES WITH READ LOCK..."
 echo "FLUSH TABLES WITH READ LOCK; SELECT SLEEP(86400);" > "$FIFO"
 sleep 2

 # 4. FREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt. Cleaning up..."
         for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         kill $(cat "$PID_FILE") 2>/dev/null
         rm -f "$FIFO" "$PID_FILE"
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 PORTNO=PORT_NUMBER
 FIFO="/tmp/mysql_backup_fifo_$PORTNO"
 PID_FILE="/tmp/mysql_backup_pid_$PORTNO"

 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)
 logger "MySQL Full VM BYOS: Starting post-snapshot script."

 # 1. UNFREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done

 # 2. RESUME DATABASE (Unlock)
 if [ -f "$PID_FILE" ]; then
     logger "MySQL Full VM BYOS: Releasing locks..."
     kill $(cat "$PID_FILE") 2>/dev/null
     rm -f "$FIFO" "$PID_FILE"
     logger "MySQL Full VM BYOS: Locks released and session closed."
 else
     logger "Error: PID file not found. Lock may have been lost prematurely."
 fi
 logger "MySQL Full VM BYOS: Cleanup complete."

Ganti kode berikut:

• DB_USER: pengguna database MySQL dengan hak istimewa administratif.
• DB_PASSWORD: sandi database MySQL (atau ambil secara dinamis dengan Secret Manager).
• PORT_NUMBER: nomor port yang digunakan MySQL untuk memproses (default: 3306).

MariaDB

Skrip pra-snapshot (/etc/google/snapshots/pre.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/pre.sh

 # 1. Configuration
 DBUSER="DB_USER"
 DBPASSWORD="DB_PASSWORD"
 PORTNO=PORT_NUMBER
 SOCKET_FILE="/var/run/mysqld/mysqld.sock"
 MARIADB_PATH="/usr/bin/mariadb" # or /usr/bin/mysql
 SRV_TYPE="Master" # Set to "Slave" for standby nodes
 FIFO="/tmp/mariadb_backup_fifo_$PORTNO"
 PID_FILE="/tmp/mariadb_backup_pid_$PORTNO"
 STARTPOS_FILE="/tmp/STARTPOS_FILE_$PORTNO.txt"

 # 2. Discovery
 # Dynamically discover all local writeable mount points for full VM consistency
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)

 logger "MariaDB Full VM BYOS: Starting pre-snapshot script."

 # 3. QUIESCE DATABASE (Session-Bound)
 # Create a FIFO to hold the session open
 rm -f "$FIFO"
 mkfifo "$FIFO"

 # Start a background mariadb session that reads from the FIFO
 # This keeps the session (and locks) active until the process is killed
 $MARIADB_PATH -u"$DBUSER" -p"$DBPASSWORD" -S"$SOCKET_FILE" -P"$PORTNO" < "$FIFO" > /tmp/mariadb_backup_output.log 2>&1 &
 echo $! > "$PID_FILE"

 # Prepare quiesce query (Logic from act_mariadb_pre.sh)
 if [ "$SRV_TYPE" != "Slave" ]; then
     # Primary node: lock all tables
     logger "MariaDB Full VM BYOS: Issuing FLUSH TABLES WITH READ LOCK..."
     echo "FLUSH TABLES WITH READ LOCK; SELECT SLEEP(86400);" > "$FIFO"

     # Capture master status for PITR/replication info
     $MARIADB_PATH -u"$DBUSER" -p"$DBPASSWORD" -S"$SOCKET_FILE" -P"$PORTNO" -e "SHOW MASTER STATUS;" > "$STARTPOS_FILE"
 else
     # Replica node: stop the slave thread
     logger "MariaDB Full VM BYOS: Issuing STOP SLAVE..."
     echo "STOP SLAVE; SELECT SLEEP(86400);" > "$FIFO"

     # Capture slave status
     $MARIADB_PATH -u"$DBUSER" -p"$DBPASSWORD" -S"$SOCKET_FILE" -P"$PORTNO" -e "SHOW SLAVE STATUS \G;" > "$STARTPOS_FILE"
 fi

 # Wait a brief moment to ensure the command is processed
 sleep 2
 # 4. FREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     if ! sudo fsfreeze -f "$mnt"; then
         logger "Error: Failed to freeze $mnt. Cleaning up..."
         # Attempt emergency thaw
         for thaw_mnt in $MOUNT_POINTS; do sudo fsfreeze -u "$thaw_mnt" 2>/dev/null; done
         # Kill the background session to release locks
         kill $(cat "$PID_FILE") 2>/dev/null
         rm -f "$FIFO" "$PID_FILE"
         exit 1
     fi
     logger "Filesystem $mnt is frozen."
 done

Skrip pasca-snapshot (/etc/google/snapshots/post.sh)

 #!/bin/bash
 # Location: /etc/google/snapshots/post.sh
 # 1. Configuration
 PORTNO=PORT_NUMBER
 SRV_TYPE="Master"
 DBUSER="DB_USER"
 DBPASSWORD="DB_PASSWORD"
 SOCKET_FILE="/var/run/mysqld/mysqld.sock"
 MARIADB_PATH="/usr/bin/mariadb"
 FIFO="/tmp/mariadb_backup_fifo_$PORTNO"
 PID_FILE="/tmp/mariadb_backup_pid_$PORTNO"
 # 2. Discovery
 MOUNT_POINTS=$(findmnt -n -l -o TARGET -t xfs,ext4,ext3,ext2,btrfs)
 logger "MariaDB Full VM BYOS: Starting post-snapshot script."
 # 3. UNFREEZE FILESYSTEMS (Optional)
 for mnt in $MOUNT_POINTS; do
     sudo fsfreeze -u "$mnt"
     logger "Filesystem $mnt is unfrozen."
 done
 # 4. RESUME DATABASE
 if [ -f "$PID_FILE" ]; then
     logger "MariaDB Full VM BYOS: Resuming database operations..."
     # Kill the background sleep process to automatically release session-bound locks
     kill $(cat "$PID_FILE") 2>/dev/null
     # For slave nodes, explicitly ensure replication is started
     if [ "$SRV_TYPE" = "Slave" ]; then
         $MARIADB_PATH -u"$DBUSER" -p"$DBPASSWORD" -S"$SOCKET_FILE" -P"$PORTNO" -e "START SLAVE;"
     fi
     rm -f "$FIFO" "$PID_FILE"
     logger "MariaDB Full VM BYOS: Cleanup complete."
 else
     logger "Error: PID file not found. Database state might be inconsistent."
 fi

Ganti kode berikut:

• DB_USER: pengguna database MariaDB dengan hak istimewa administratif.
• DB_PASSWORD: sandi database MariaDB (atau ambil secara dinamis dengan Secret Manager).
• PORT_NUMBER: nomor port yang digunakan MariaDB untuk memproses permintaan (default: 3306).

Men-deploy skrip pengosongan tamu

Setelah menyiapkan skrip pre.sh dan post.sh untuk database, deploy skrip tersebut ke instance VM Linux:

1. Hubungkan ke instance VM Linux yang menjalankan database yang dikelola sendiri menggunakan SSH.

2. Buat direktori /etc/google/snapshots/ jika belum ada:

   sudo mkdir -p /etc/google/snapshots
   

3. Simpan skrip pre.sh dan post.sh kustom Anda ke direktori /etc/google/snapshots/ di instance VM.

4. Pastikan skrip memiliki izin eksekusi:

   sudo chmod 755 /etc/google/snapshots/pre.sh /etc/google/snapshots/post.sh
   

Mengaktifkan agen tamu untuk snapshot

Untuk mengizinkan Backup and DR menjalankan skrip sebelum dan sesudah snapshot, aktifkan integrasi snapshot di lingkungan tamu Compute Engine pada instance VM Linux Anda:

1. Hubungkan ke instance VM Linux yang menjalankan database yang dikelola sendiri menggunakan SSH (jika belum terhubung).

2. Buka file konfigurasi lingkungan tamu di editor teks:

   sudo nano /etc/default/instance_configs.cfg
   

3. Tambahkan atau ubah setelan berikut di bagian [Snapshots] untuk mengaktifkan snapshot:

   [Snapshots]
   enabled = true
   timeout_in_seconds = 120
   

   Catatan: Parameter timeout_in_seconds menentukan waktu maksimum agen tamu menunggu hingga skrip pre.sh dan post.sh selesai. Sesuaikan nilai ini untuk mengakomodasi durasi operasi penghentian sementara database atau pembekuan sistem file.

4. Mulai ulang agen tamu di instance VM untuk menerapkan perubahan:

   sudo systemctl restart google-guest-agent
   

Mengonfigurasi rencana cadangan

Setelah instance VM dikonfigurasi dengan skrip pengosongan tamu dan agen tamu diaktifkan untuk snapshot, konfigurasi rencana pencadangan di konsol Google Cloud :

1. Di konsol Google Cloud , buka halaman Backup and DR.

   Buka Backup and DR

2. Dari menu navigasi, pilih Rencana Pencadangan.

3. Klik Buat Rencana Pencadangan, atau pilih rencana pencadangan yang ada, lalu klik Edit.

4. Di bagian langkah-langkah konfigurasi Pencadangan Instance, temukan opsi konsistensi.

5. Pilih opsi Aktifkan Konsistensi Aplikasi.

6. Simpan dan terapkan rencana pencadangan ke instance VM Anda. Sesuai jadwal, rencana pencadangan memicu agen tamu untuk menjalankan skrip pre.sh Anda, mengambil snapshot, dan menjalankan skrip post.sh.

Mengonfigurasi pencadangan Persistent Disk untuk pemulihan point-in-time database

Untuk database yang dikelola sendiri seperti Db2 dan SAP HANA, Anda dapat mengonfigurasi pencadangan Persistent Disk mandiri untuk merekam log arsip database, sehingga memungkinkan pemulihan point-in-time. Jika tidak memerlukan pemulihan point-in-time, Anda dapat langsung membaca Menonaktifkan skrip guest-flush.

Praktik terbaik untuk pencadangan log pemulihan point-in-time

• Frekuensi: Konfigurasi jadwal rencana pencadangan untuk disk log khusus ini agar sama dengan perincian log pemulihan point-in-time Anda, misalnya, setiap 15 menit atau setiap jam.

• Pengoptimalan biaya: Menyimpan snapshot yang sering dapat meningkatkan biaya penyimpanan. Untuk meminimalkan overhead, konfigurasikan periode retensi data minimum dan periode brankas keabadian yang sesuai ke waktu minimum yang diizinkan yang masih memenuhi jendela pemulihan point-in-time Anda.

Memulihkan database yang dikelola sendiri ke titik waktu tertentu

Jika Anda telah mengonfigurasi pencadangan VM reguler bersama dengan pencadangan log Persistent Disk khusus, ikuti prosedur ini untuk memulihkan database Anda ke titik waktu tertentu. Jika Anda tidak mengonfigurasi pencadangan log khusus atau tidak memerlukan pemulihan point-in-time, lihat Memulihkan instance Compute Engine dari vault cadangan untuk memulihkan VM Anda secara langsung, dan lanjutkan ke Melakukan tugas pasca-pemulihan.

Alur kerja pemulihan

1. Pulihkan VM dasar: Pilih cadangan instance (image mesin) dari vault cadangan yang mendahului waktu pemulihan target Anda. Pulihkan dengan mengikuti prosedur pemulihan Compute Engine standar. Untuk mengetahui petunjuknya, lihat Memulihkan instance Compute Engine dari vault cadangan.

   Jika Anda tidak mengonfigurasi pencadangan log khusus atau tidak memerlukan pemulihan point-in-time, lanjutkan ke langkah 4.

2. Lampirkan disk log: Identifikasi dan pulihkan snapshot disk log yang relevan yang diambil hingga waktu pemulihan target Anda. Pasang disk yang baru dibuat ini ke instance yang dipulihkan.

   Catatan: Anda dapat memulihkan persistent disk menggunakan konsol Google Cloud atau menggunakan gcloud CLI selama prosedur teruskan. Anda mungkin perlu memasang beberapa disk cadangan log untuk memastikan semua log yang diarsipkan penting tersedia.

3. Lakukan roll forward database: Hubungkan ke instance yang dipulihkan menggunakan SSH dan jalankan perintah roll forward khusus database—seperti ROLLFORWARD DATABASE di Db2—menggunakan log yang ada di disk persisten yang baru dilampirkan.

4. Lakukan tugas pasca-pemulihan: Lakukan langkah-langkah khusus database yang diperlukan untuk mengaktifkan aplikasi.

   Perhatian: Pastikan konfigurasi database diperbarui jika nama VM yang dipulihkan atau jalur disk terpasang berbeda dari lingkungan sumber.

Menonaktifkan skrip guest-flush

Untuk menghapus skrip guest-flush kustom dan menonaktifkan konsistensi aplikasi:

1. Batalkan penetapan rencana pencadangan dari instance Anda: Di konsol Google Cloud , buka halaman Backup and DR, temukan instance VM Anda di bagian Protected Resources, lalu batalkan penetapan atau hapus penetapan rencana pencadangan.

2. Hapus skrip guest-flush: Hubungkan ke instance VM Linux Anda menggunakan SSH dan hapus skrip guest-flush kustom:

   sudo rm -f /etc/google/snapshots/pre.sh /etc/google/snapshots/post.sh
   

3. Nonaktifkan integrasi snapshot di guest agent: Buka /etc/default/instance_configs.cfg di instance VM Anda, tetapkan enabled = false di bagian [Snapshots], dan mulai ulang guest agent:

   sudo systemctl restart google-guest-agent
   

Langkah berikutnya

• Membuat dan mengelola rencana pencadangan
• Memantau tugas pencadangan dan pemulihan
• Mencadangkan instance Compute Engine
• Memulihkan instance Compute Engine
• Mencadangkan Persistent Disk
• Memulihkan Persistent Disk