Sicherungs-Repository für Database Service erstellen

In diesem Dokument werden die Schritte zum Konfigurieren der erforderlichen BackupRepository für den Database Service (DBS) von Google Distributed Cloud (GDC) mit Air Gap beschrieben. Dieses Repository, das obligatorisch den Namen dbs-backup-repository hat, ist eine benutzerdefinierte Ressource in Kubernetes, die den GDC-Sicherungsdienst an einen S3-kompatiblen Objektspeicher-Bucket zum Speichern von Datenbanksicherungen weiterleitet.

Eine ordnungsgemäße Einrichtung ist entscheidend, um Sicherungs- und Wiederherstellungsfunktionen für DBS-Instanzen wie PostgreSQL, Oracle und AlloyDB Omni zu aktivieren.

Hinweis

Bevor Sie beginnen, sollten Sie prüfen, ob die folgenden Voraussetzungen erfüllt sind:

  • Projekt: Ein Projekt zum Hosten des Buckets, normalerweise mit dem Namen backups, auf das nur Dienstkonten zugreifen können.
  • Zugriff: Ausreichende Berechtigungen für die Interaktion mit dem Management API-Server.
    • Der Nutzer muss die folgenden Rollen auf Organisationsebene haben, um das Backup-Repository zu erstellen:
      • Bucket-Administrator (bucket-admin)
      • Projektersteller (project-creator)
      • Administrator für Sicherungen der Organisation (organization-backup-admin)
    • Innerhalb des Zielprojekts:
      • IAM-Projektadministrator (project-iam-admin)
      • Bucket-Objekt-Projekt-Betrachter (project-bucket-object-viewer)
      • Bucket-Objekt-Projektadministrator (project-bucket-object-admin)
      • Bucket-Projektadministrator (project-bucket-admin)
      • Secret-Betrachter (secret-viewer)
      • Namespace-Administrator (namespace-admin)
      • Backup Creator (backup-creator)
  • Tools:
    • Die GDC-Konsole.
    • kubectl-Befehlszeile für den Zugriff auf den Verwaltungs-API-Server konfiguriert.

Objektspeicher-Bucket erstellen

Alle nachfolgenden Schritte werden auf dem Management API-Server ausgeführt. Bucket-Ressource definieren und erstellen Für den Rest dieses Dokuments wird der empfohlene Name dbs-backups für diesen Storage-Bucket im Projekt-Namespace backups verwendet. Achten Sie darauf, dass für den Bucket keine Aufbewahrungsrichtlinie festgelegt ist.

Console

  1. Melden Sie sich in der GDC-Konsole für die Organisation an.
  2. Sie müssen sich im Projekt backups befinden.
  3. Rufen Sie Objektspeicher > Buckets auf.
  4. Klicken Sie auf Bucket erstellen.
  5. Legen Sie als Bucket-Namen dbs-backups fest.
  6. Legen Sie als Beschreibung Bucket for DBS backups fest.
  7. Konfigurieren Sie die Speicherklasse nach Bedarf. Beispiel: Standard.
  8. Achten Sie darauf, dass Sie für Sicherheit keine Aufbewahrungsrichtlinie festlegen, da dies dazu führt, dass Datenbanken und ihre Sicherungen fälschlicherweise aufbewahrt werden.
  9. Klicken Sie auf Erstellen.

API

  • Wenden Sie das folgende Manifest auf den Management API-Server an:
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
<<EOF
apiVersion: object.gdc.goog/v1
kind: Bucket
metadata:
  name: dbs-backups
  namespace: backups
spec:
  description: "Bucket for DBS backups"
  storageClass: "Standard"
EOF

Dienstkonto erstellen und Berechtigungen festlegen

Erstellen Sie ein ProjectServiceAccount und gewähren Sie ihm Berechtigungen für den Zugriff auf den Bucket.

Console

  1. Rufen Sie im Projekt backups Identität und Zugriff > Dienstidentitäten auf.
  2. Klicken Sie auf Dienstidentität erstellen. Die Seite Details zur Dienstidentität wird geöffnet.
  3. Geben Sie im Feld Name der Dienstidentität dbs-backup-sa ein.
  4. Klicken Sie auf Erstellen.
  5. Gehen Sie zu Identität und Zugriff > Zugriff.
  6. Klicken Sie in der Liste Mitglied auf Mitglied hinzufügen. Die Seite Nutzer und Rollen wird angezeigt.
  7. Wählen Sie in der Liste Mitgliedstyp die Option Dienstidentität aus.
  8. Wählen Sie in der Liste Dienstidentität die Option dbs-backup-sa aus, um eine Rollenbindung zuzuweisen.
  9. Wählen Sie in der Liste Rolle die Option Bucket Object Project Admin aus, um sie der Dienstidentität zuzuweisen.
  10. Klicken Sie auf Hinzufügen.

API

  • Wenden Sie diese Manifeste auf den Management API-Server an:
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
<<EOF
apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectServiceAccount
metadata:
  name: dbs-backup-sa
  namespace: backups
spec: {}
EOF
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
<<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dbs-backups-readwrite-rolebinding
  namespace: backups
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: project-bucket-object-admin
subjects:
- kind: ServiceAccount
  name: dbs-backup-sa
  namespace: backups
EOF

Anmeldedaten-Secret und Bucket-Details des Dienstkontos ermitteln

Nachdem Sie dem dbs-backup-sa Bucket-Zugriff gewährt haben, erstellt GDC automatisch ein Secret im selben Namespace, backups, das die S3-Zugriffsanmeldedaten enthält. Sie müssen den Namen dieses Secrets und die Bucket-Details mithilfe der kubectl-Befehlszeile (API) ermitteln.

  1. Legen Sie Umgebungsvariablen fest:

    export SA_NAMESPACE="backups"
    export SA_NAME="dbs-backup-sa"
    export KUBECONFIG=MANAGEMENT_API_SERVER
    
  2. Suchen Sie den Secret-Namen:

    export BUCKET_CRED_SECRET_NAME=$(kubectl --kubeconfig=${KUBECONFIG} get secret \
        -n "${SA_NAMESPACE}" -l object.gdc.goog/subject-type=ServiceAccount -o json | \
        jq -r --arg SA_NAME "${SA_NAME}" \
        '.items[] | select(.metadata.annotations["object.gdc.goog/subject"] == $SA_NAME and (.metadata.name |startswith("object-storage-key-std-sa-"))) | .metadata.name')
    echo "Bucket Credential Secret Name: ${BUCKET_CRED_SECRET_NAME}"
    

    Mit diesem Befehl werden Secrets im Namespace backups gefiltert, um das Secret zu finden, das für das Dienstkonto dbs-backup-sa annotiert ist und der Standard-Namenskonvention entspricht. Zum Ausführen dieses Befehls benötigen Sie die Rolle „Secret Viewer“ (secret-viewer) im Projekt backups. Alternativ können Sie den Plattformadministrator, der das Dienstkonto erstellt hat, bitten, den Secret-Namen anzugeben.

  3. Rufen Sie die Details zum Bucket-Endpunkt und zur Region ab:

    export BUCKET_NAME=dbs-backups
    export FULL_BUCKET_NAME=$(kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${SA_NAMESPACE} ${BUCKET_NAME} -o jsonpath='{.status.fullyQualifiedName}')
    export ENDPOINT=$(kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${SA_NAMESPACE} ${BUCKET_NAME} -o jsonpath='{.status.endpoint}')
    export REGION=$(kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${SA_NAMESPACE} ${BUCKET_NAME} -o jsonpath='{.status.region}')
    
    echo "FULL_BUCKET_NAME: ${FULL_BUCKET_NAME}"
    echo "ENDPOINT: ${ENDPOINT}"
    echo "REGION: ${REGION}"
    

BackupRepository erstellen

Erstellen Sie die Ressource BackupRepository und verweisen Sie dabei auf das Secret, das Sie im vorherigen Abschnitt Anmeldedaten-Secret und Bucket-Details des Dienstkontos ermitteln identifiziert haben. Dieser Schritt muss mit der kubectl-Befehlszeile (API) ausgeführt werden.

  • Erstellen Sie die YAML-Datei, z. B. backup-repo.yaml, und ersetzen Sie die Variablen aus dem vorherigen Abschnitt:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
    <<EOF
    apiVersion: backup.gdc.goog/v1
    kind: BackupRepository
    metadata:
      name: dbs-backup-repository # This specific name is required for DBS
    spec:
      secretReference:
        namespace: "backups" # Namespace of the Service Account and the auto-generated secret
        name: BUCKET_CRED_SECRET_NAME
      endpoint: ENDPOINT
      type: "S3"
      s3Options:
        bucket: FULL_BUCKET_NAME
        region: REGION
        forcePathStyle: true
      importPolicy: "ReadWrite"
      force: true
      EOF
    

    Ersetzen Sie Folgendes:

    • BUCKET_CRED_SECRET_NAME: der Secret-Name.
    • ENDPOINT: der Endpunkt des Buckets.
    • FULL_BUCKET_NAME: der vollständig qualifizierte Bucket-Name.
    • REGION: die Region des Buckets.

Backup-Repository prüfen

Prüfen Sie den Repository-Status, um sicherzustellen, dass es korrekt eingerichtet wurde.

  1. Geben Sie die Informationen für Ihr Backup-Repository aus:

    kubectl --kubeconfig MANAGEMENT_API_SERVER get backuprepository dbs-backup-repository -ojson | jq .status
    
  2. Die Ausgabe sollte in etwa so aussehen: Die Meldung NoError ist das Signal, dass das Repository wie erwartet eingerichtet wurde:

    NAME                    TYPE   POLICY      ERROR
    dbs-backup-repository   S3     ReadWrite   NoError
    status:
      conditions:
      - lastTransitionTime: "2025-11-13T00:36:09Z"
        message: Backup Repository reconciled successfully
        reason: Ready
        status: "True"
        type: Ready
      initialImportDone: true
      reconciliationError: NoError
      sentinelEtag: 9b82fbb7-6ea2-444d-8878-ab91397ae961