Zum Inhalt

Backup & Restore

Diese Seite beschreibt, wie Anwendungsentwickler auf der ayedo Software Delivery Plattform auf ihre Datenbank-Backups zugreifen und diese herunterladen können.

Zielgruppe

Dieser Guide richtet sich an Anwendungsentwickler, die ihre CloudNativePG Datenbank-Backups herunterladen, überprüfen oder für lokale Entwicklung/Debugging nutzen möchten.

Überblick

Auf der ayedo Software Delivery Plattform werden PostgreSQL-Datenbanken mit CloudNativePG bereitgestellt. CloudNativePG erstellt automatische Backups, die auf einem S3-kompatiblen Object Storage gespeichert werden.

graph LR
    A[CloudNativePG Cluster] --> B[Continuous Archiving]
    B --> C[S3 Object Storage]
    C --> D[Backup Download via mc]
    D --> E[Lokale Analyse/Restore]

Backup-Typen:

  • Base Backups: Vollständige Datenbank-Snapshots (täglich)
  • WAL-Archive: Write-Ahead-Logs für Point-in-Time Recovery

Zugangsdaten anfordern

Managed Software Delivery Platform Kunden

Kunden der ayedo Managed Software Delivery Platform können Zugangsdaten für ihre Backups anfordern:

Kontaktieren Sie das ayedo Support-Team:

Geben Sie folgende Informationen an:

  • Projektname / Namespace
  • Name des CloudNativePG Clusters
  • Gewünschter Zugriffszeitraum (falls temporär)

Sie erhalten:

  • S3 Endpoint URL
  • Access Key ID
  • Secret Access Key
  • Bucket Name
  • Pfad zu Ihren Backups

Sicherheitshinweis

Behandeln Sie die erhaltenen Zugangsdaten vertraulich. Speichern Sie diese niemals in Git-Repositories oder teilen Sie diese nicht mit unbefugten Personen.

Self-Managed Platform

Wenn Sie die ayedo Software Delivery Plattform selbst betreiben, können Sie die S3-Zugangsdaten aus dem CloudNativePG Cluster Secret auslesen:

# Secret-Name finden (Format: <db-name>-s3-credentials)
kubectl get secrets -n <namespace> | grep s3-credentials

# Zugangsdaten auslesen
kubectl get secret <db-name>-s3-credentials -n <namespace> -o jsonpath='{.data.ACCESS_KEY_ID}' | base64 -d
kubectl get secret <db-name>-s3-credentials -n <namespace> -o jsonpath='{.data.ACCESS_SECRET_KEY}' | base64 -d

MinIO Client (mc) installieren

Der MinIO Client (mc) ist ein leistungsfähiges CLI-Tool für die Arbeit mit S3-kompatiblem Object Storage. Er unterstützt alle S3-kompatiblen Backends wie MinIO, AWS S3, Ceph, und andere.

Installation

# Binary herunterladen
curl -O https://dl.min.io/client/mc/release/linux-amd64/mc

# Ausführbar machen
chmod +x mc

# In PATH verschieben
sudo mv mc /usr/local/bin/

# Installation verifizieren
mc --version

# Binary herunterladen
curl -O https://dl.min.io/client/mc/release/linux-arm64/mc

# Ausführbar machen
chmod +x mc

# In PATH verschieben
sudo mv mc /usr/local/bin/

# Installation verifizieren
mc --version

# Via Homebrew (empfohlen)
brew install minio/stable/mc

# Oder manuell
curl -O https://dl.min.io/client/mc/release/darwin-amd64/mc
chmod +x mc
sudo mv mc /usr/local/bin/

# Via Homebrew (empfohlen)
brew install minio/stable/mc

# Oder manuell
curl -O https://dl.min.io/client/mc/release/darwin-arm64/mc
chmod +x mc
sudo mv mc /usr/local/bin/

# Via winget
winget install minio.mc

# Oder manuell herunterladen
# https://dl.min.io/client/mc/release/windows-amd64/mc.exe
# In PATH hinzufügen

mc konfigurieren

Konfigurieren Sie mc mit Ihren S3-Zugangsdaten:

# Alias für ayedo Backup Storage hinzufügen
mc alias set ayedo-backup https://s3.example.com ACCESS_KEY_ID SECRET_ACCESS_KEY

# Beispiel mit konkreten Werten:
mc alias set ayedo-backup https://backup.ayedo.cloud AKIAIOSFODNN7EXAMPLE wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Parameter:

Parameter Beschreibung
ayedo-backup Frei wählbarer Alias-Name für diese Verbindung
https://s3.example.com S3 Endpoint URL (von ayedo bereitgestellt)
ACCESS_KEY_ID Ihr Access Key (von ayedo bereitgestellt)
SECRET_ACCESS_KEY Ihr Secret Key (von ayedo bereitgestellt)

Konfiguration verifizieren:

# Verbindung testen
mc admin info ayedo-backup

# Buckets auflisten
mc ls ayedo-backup

Mehrere Aliase

Sie können mehrere Aliase konfigurieren, z.B. für verschiedene Umgebungen:

mc alias set ayedo-staging https://backup-staging.ayedo.cloud ... ...
mc alias set ayedo-production https://backup-prod.ayedo.cloud ... ...

mc Konfigurationsdatei

Die mc-Konfiguration wird in einer JSON-Datei gespeichert. Sie können diese Datei auch direkt bearbeiten, anstatt mc alias set zu verwenden.

Speicherort der Konfigurationsdatei:

Betriebssystem Pfad
Linux ~/.mc/config.json
macOS ~/.mc/config.json
Windows %USERPROFILE%\.mc\config.json

Beispiel einer mc config.json:

{
    "version": "10",
    "aliases": {
        "ayedo-backup": {
            "url": "https://backup.ayedo.cloud",
            "accessKey": "AKIAIOSFODNN7EXAMPLE",
            "secretKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
            "api": "s3v4",
            "path": "auto"
        }
    }
}

Konfiguration direkt bearbeiten:

# Konfigurationsdatei öffnen
nano ~/.mc/config.json

# Oder mit einem anderen Editor
code ~/.mc/config.json
vim ~/.mc/config.json

Felder im Alias-Objekt:

Feld Beschreibung
url S3 Endpoint URL
accessKey Access Key ID
secretKey Secret Access Key
api API-Signatur-Version (s3v4 für moderne S3-Implementierungen)
path Path-Style (auto, on, off)

Fertige Konfiguration von ayedo

Auf Wunsch stellt ayedo Ihnen die Zugangsdaten im mc-Konfigurationsformat bereit. Sie können den erhaltenen JSON-Block direkt in Ihre config.json unter aliases einfügen:

{
    "version": "10",
    "aliases": {
        "ayedo-backup": {
            "url": "https://backup.ayedo.cloud",
            "accessKey": "IHR_ACCESS_KEY",
            "secretKey": "IHR_SECRET_KEY",
            "api": "s3v4",
            "path": "auto"
        }
    }
}

Kontaktieren Sie support@ayedo.de und fordern Sie Ihre Zugangsdaten im mc-Format an.

Mit Backups arbeiten

Backup-Struktur verstehen

CloudNativePG organisiert Backups in einer definierten Verzeichnisstruktur. Jede Datenbank erhält einen eigenen Bucket mit einem eindeutigen Identifier:

<alias>/
└── <unique-id>/
    └── <db-name>/
        ├── base/                    # Base Backups
        │   ├── 20250101T020000/    # Backup vom 01.01.2025 02:00
        │   │   ├── backup_manifest
        │   │   ├── data.tar.gz
        │   │   └── ...
        │   └── 20250102T020000/    # Backup vom 02.01.2025 02:00
        │       └── ...
        └── wals/                    # WAL Archive
            ├── 0000000100000000/
            │   ├── 000000010000000000000001.gz
            │   ├── 000000010000000000000002.gz
            │   └── ...
            └── ...

Beispiel eines produktiven Pfads:

# Alias: my-db-backups
# Pfad zu Base Backups:
mc ls my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/
Komponente Beispiel Beschreibung
Alias my-db-backups Ihr mc-Alias für diesen Backup-Bucket
Unique ID mydb-cnpg-a1b2c3d4e5f6 Eindeutiger CloudNativePG Cluster-Identifier
DB Name mydb Name der Datenbank
Backup-Typ base/ oder wals/ Base Backups oder WAL-Archive

Backups auflisten

# Root-Verzeichnis des Buckets anzeigen
mc ls my-db-backups/

# Zum Datenbank-Verzeichnis navigieren
mc ls my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/

# Base Backups auflisten
mc ls my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/

# WAL-Archive auflisten
mc ls my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/wals/

Beispielausgabe:

[2025-01-01 02:15:23 UTC]     0B 20250101T020000/
[2025-01-02 02:18:45 UTC]     0B 20250102T020000/
[2025-01-03 02:12:33 UTC]     0B 20250103T020000/

Backup-Details anzeigen

# Inhalt eines spezifischen Backups anzeigen
mc ls my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/20250103T020000/

# Backup-Manifest anzeigen (enthält Metadaten)
mc cat my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/20250103T020000/backup_manifest

Backups herunterladen

Einzelnes Backup herunterladen

# Lokales Verzeichnis erstellen
mkdir -p ~/backups/mydb

# Komplettes Base Backup herunterladen
mc cp --recursive \
  my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/20250103T020000/ \
  ~/backups/mydb/20250103T020000/

Alle Backups herunterladen

# Alle Base Backups herunterladen
mc cp --recursive \
  my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/ \
  ~/backups/mydb/base/

# WAL-Archive herunterladen (für Point-in-Time Recovery)
mc cp --recursive \
  my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/wals/ \
  ~/backups/mydb/wals/

Mit Fortschrittsanzeige

# Download mit Fortschrittsanzeige
mc cp --recursive --progress \
  my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/20250103T020000/ \
  ~/backups/mydb/

Backup-Integrität prüfen

# Dateigröße und Checksummen anzeigen
mc stat my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/20250103T020000/data.tar.gz

# MD5-Hash für heruntergeladene Datei berechnen
md5sum ~/backups/mydb/20250103T020000/data.tar.gz

Recovery-Methoden

CloudNativePG erstellt physische Backups (basierend auf pg_basebackup), keine logischen Dumps (pg_dump). Das bedeutet, dass die Wiederherstellung anders funktioniert als bei SQL-Dump-Dateien.

Physische vs. Logische Backups

  • Physische Backups (CloudNativePG): Binärkopie des PostgreSQL-Datenverzeichnisses + WAL-Archive
  • Logische Backups (pg_dump): SQL-Statements zur Rekonstruktion der Datenbank

Physische Backups ermöglichen Point-in-Time Recovery (PITR) und sind schneller bei großen Datenbanken, erfordern aber dieselbe PostgreSQL-Major-Version.

Methode 1: CNPG In-Cluster Recovery (empfohlen)

Die bevorzugte Methode ist die Wiederherstellung über CloudNativePG selbst. Dabei wird ein neuer Cluster aus dem Backup gebootstrapped - Recovery erfolgt nicht "in-place".

Wann In-Cluster Recovery nutzen?

  • Production-Wiederherstellung nach Datenverlust
  • Point-in-Time Recovery zu einem bestimmten Zeitpunkt
  • Klonen einer Datenbank für Testing/Staging

Beispiel: Recovery aus Object Store

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore
  namespace: my-namespace
spec:
  instances: 3

  # Superuser-Secret (optional, wird sonst generiert)
  superuserSecret:
    name: superuser-secret

  bootstrap:
    recovery:
      source: clusterBackup
      # Optional: Point-in-Time Recovery
      # recoveryTarget:
      #   targetTime: "2025-01-03T10:30:00Z"

  storage:
    size: 50Gi
    storageClass: longhorn

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: s3://my-db-backups/
        endpointURL: https://backup.ayedo.cloud
        s3Credentials:
          accessKeyId:
            name: s3-credentials
            key: ACCESS_KEY_ID
          secretAccessKey:
            name: s3-credentials
            key: ACCESS_SECRET_KEY
        wal:
          maxParallel: 8  # Parallele WAL-Wiederherstellung

Point-in-Time Recovery (PITR) Optionen:

Target Beschreibung
targetTime Zeitstempel im RFC 3339 Format (z.B. 2025-01-03T10:30:00Z)
targetLSN WAL Log Sequence Number
targetXID Transaction ID
targetName Benannter Restore Point (pg_create_restore_point())
targetImmediate Sobald konsistenter Zustand erreicht ist

Weitere Details in der CloudNativePG Recovery Dokumentation.

Methode 2: Manueller Restore mit Barman Tools

Für die manuelle Wiederherstellung außerhalb eines Kubernetes-Clusters können Sie die Barman Cloud Tools verwenden. Diese sind dieselben Tools, die CloudNativePG intern nutzt.

Barman Cloud Tools installieren

# Via pip (Python 3.8+)
pip install barman[cloud]

# Oder via pipx (isolierte Installation)
pipx install barman[cloud]

# Verfügbare Tools prüfen
barman-cloud-restore --help
barman-cloud-wal-restore --help

Base Backup wiederherstellen

# Umgebungsvariablen für S3-Zugriff
export AWS_ACCESS_KEY_ID="IHR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="IHR_SECRET_KEY"

# Zielverzeichnis erstellen
mkdir -p /var/lib/postgresql/16/restore

# Base Backup herunterladen und entpacken
barman-cloud-restore \
  --cloud-provider aws-s3 \
  --endpoint-url https://backup.ayedo.cloud \
  s3://my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb \
  20250103T020000 \
  /var/lib/postgresql/16/restore

WAL-Archive für PITR wiederherstellen

# Recovery-Konfiguration erstellen
cat > /var/lib/postgresql/16/restore/postgresql.auto.conf << EOF
restore_command = 'barman-cloud-wal-restore --cloud-provider aws-s3 --endpoint-url https://backup.ayedo.cloud s3://my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb %f %p'
recovery_target_time = '2025-01-03 10:30:00+00'
EOF

# Recovery Signal erstellen
touch /var/lib/postgresql/16/restore/recovery.signal

# PostgreSQL starten
sudo -u postgres pg_ctl -D /var/lib/postgresql/16/restore start

Methode 3: Manueller Restore mit mc + PostgreSQL

Wenn Sie die Barman Tools nicht nutzen können oder wollen, können Sie das Backup manuell mit mc herunterladen und mit PostgreSQL-Bordmitteln wiederherstellen.

Voraussetzungen

  • PostgreSQL gleiche Major-Version wie das Backup (z.B. PostgreSQL 16)
  • Ausreichend Speicherplatz (mindestens 2x Backup-Größe)
  • mc konfiguriert mit Zugriff auf den Backup-Bucket

Schritt 1: Backup herunterladen

# Backup-Verzeichnis erstellen
mkdir -p ~/backups/mydb/20250103T020000

# Base Backup herunterladen
mc cp --recursive \
  my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/20250103T020000/ \
  ~/backups/mydb/20250103T020000/

# WAL-Archive herunterladen (für PITR)
mc cp --recursive \
  my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/wals/ \
  ~/backups/mydb/wals/

Schritt 2: Backup-Struktur analysieren

# Backup-Inhalt anzeigen
ls -la ~/backups/mydb/20250103T020000/

# Typische Struktur:
# data.tar.gz     - Komprimiertes Datenverzeichnis
# backup_manifest - Backup-Metadaten

Schritt 3: Datenverzeichnis vorbereiten

# Bestehendes Datenverzeichnis sichern (falls vorhanden)
sudo systemctl stop postgresql
sudo mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main.backup

# Neues Verzeichnis erstellen
sudo mkdir -p /var/lib/postgresql/16/main
sudo chown postgres:postgres /var/lib/postgresql/16/main
sudo chmod 700 /var/lib/postgresql/16/main

# Backup entpacken
sudo -u postgres tar -xzf ~/backups/mydb/20250103T020000/data.tar.gz \
  -C /var/lib/postgresql/16/main

Schritt 4: Recovery konfigurieren

# WAL-Verzeichnis vorbereiten
mkdir -p ~/backups/mydb/wals-extracted
for f in ~/backups/mydb/wals/*/*.gz; do
  gunzip -c "$f" > ~/backups/mydb/wals-extracted/$(basename "${f%.gz}")
done

# Recovery-Konfiguration
sudo -u postgres tee /var/lib/postgresql/16/main/postgresql.auto.conf << EOF
restore_command = 'cp ~/backups/mydb/wals-extracted/%f %p'
recovery_target_time = '2025-01-03 10:30:00+00'
recovery_target_action = 'promote'
EOF

# Recovery Signal
sudo -u postgres touch /var/lib/postgresql/16/main/recovery.signal

Schritt 5: PostgreSQL starten

# PostgreSQL starten
sudo systemctl start postgresql

# Recovery-Fortschritt überwachen
sudo tail -f /var/log/postgresql/postgresql-16-main.log

# Nach erfolgreicher Recovery: Verbinden und prüfen
psql -U postgres -c "SELECT pg_is_in_recovery();"
# Sollte "f" (false) zurückgeben nach Abschluss der Recovery

Methode 4: Restore mit Docker (Entwicklung/Testing)

Für schnelle lokale Tests können Sie Docker nutzen:

# Backup-Verzeichnis vorbereiten
mkdir -p ~/pg-restore
tar -xzf ~/backups/mydb/20250103T020000/data.tar.gz -C ~/pg-restore/

# PostgreSQL Container mit wiederhergestellten Daten starten
docker run -d \
  --name pg-restore \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -v ~/pg-restore:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

# Verbindung testen
psql -h localhost -U postgres -c "\l"

Daten extrahieren mit pg_dump

Nach erfolgreicher Wiederherstellung können Sie mit pg_dump einen logischen Export erstellen. Dies ist nützlich für:

  • Portabilität zwischen PostgreSQL-Versionen
  • Selektive Wiederherstellung einzelner Tabellen
  • Migration zu anderen Datenbank-Systemen

Vollständiger Datenbank-Dump

# SQL-Format (lesbar, portabel)
pg_dump -h localhost -U postgres -d mydb \
  --format=plain \
  --file=mydb-dump.sql

# Custom-Format (komprimiert, selektive Wiederherstellung)
pg_dump -h localhost -U postgres -d mydb \
  --format=custom \
  --file=mydb-dump.dump

# Mit Komprimierung
pg_dump -h localhost -U postgres -d mydb \
  --format=custom \
  --compress=9 \
  --file=mydb-dump.dump.gz

Einzelne Tabellen exportieren

# Bestimmte Tabelle exportieren
pg_dump -h localhost -U postgres -d mydb \
  --table=users \
  --format=plain \
  --file=users-table.sql

# Mehrere Tabellen
pg_dump -h localhost -U postgres -d mydb \
  --table=users --table=tickets --table=articles \
  --format=custom \
  --file=selected-tables.dump

Schema-only Export

# Nur Schema (keine Daten)
pg_dump -h localhost -U postgres -d mydb \
  --schema-only \
  --file=mydb-schema.sql

Wiederherstellung mit pg_restore

# Custom-Format wiederherstellen
pg_restore -h localhost -U postgres -d target_db \
  --clean --if-exists \
  mydb-dump.dump

# Selektive Wiederherstellung (nur bestimmte Tabelle)
pg_restore -h localhost -U postgres -d target_db \
  --table=users \
  mydb-dump.dump

# SQL-Format wiederherstellen
psql -h localhost -U postgres -d target_db < mydb-dump.sql

Tooling-Übersicht

Tool Verwendung Wann nutzen
CNPG Recovery In-Cluster Wiederherstellung Production, PITR, Cluster-Klonen
barman-cloud-restore Physisches Backup herunterladen Externe Wiederherstellung mit PITR
mc S3-Dateien herunterladen Manueller Download, Backup-Inspektion
pg_dump Logischen Export erstellen Portabilität, selektive Extraktion
pg_restore Custom-Format wiederherstellen Logische Dumps importieren
psql SQL-Dumps ausführen Plain-SQL-Format importieren

Nützliche mc-Befehle

Allgemeine Befehle

Befehl Beschreibung
mc ls <alias>/<bucket>/ Verzeichnisinhalt auflisten
mc cp <src> <dst> Dateien kopieren
mc rm <path> Dateien löschen
mc cat <path> Dateiinhalt anzeigen
mc stat <path> Datei-Metadaten anzeigen
mc find <path> --name "*.gz" Dateien suchen
mc du <path> Speicherverbrauch anzeigen
mc diff <path1> <path2> Verzeichnisse vergleichen
mc mirror <src> <dst> Verzeichnisse synchronisieren

Backup-spezifische Beispiele

# Größe aller Backups anzeigen
mc du my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/

# Nur Backups der letzten 7 Tage anzeigen
mc find my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/ \
  --newer-than 7d

# Backup-Manifest aller Backups anzeigen
for backup in $(mc ls my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/ --json | jq -r '.key'); do
  echo "=== $backup ==="
  mc cat my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/$backup/backup_manifest
done

# Speicherverbrauch nach Backup-Typ
echo "Base Backups:"
mc du my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/base/
echo "WAL Archives:"
mc du my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/wals/

Automatisierte Scripts

Backup-Download-Script:

#!/bin/bash
# download-backup.sh - Lädt das neueste Backup herunter

# Konfiguration - an Ihre Umgebung anpassen
ALIAS="my-db-backups"
UNIQUE_ID="mydb-cnpg-a1b2c3d4e5f6"
DB_NAME="mydb"
LOCAL_DIR="$HOME/backups/$DB_NAME"

BACKUP_PATH="$ALIAS/$UNIQUE_ID/$DB_NAME/base"

# Neuestes Backup finden
LATEST=$(mc ls $BACKUP_PATH/ --json | \
  jq -rs 'sort_by(.lastModified) | last | .key')

if [ -z "$LATEST" ]; then
  echo "Kein Backup gefunden!"
  exit 1
fi

echo "Lade neuestes Backup herunter: $LATEST"
mkdir -p "$LOCAL_DIR"

mc cp --recursive --progress \
  "$BACKUP_PATH/$LATEST" \
  "$LOCAL_DIR/$LATEST"

echo "Backup heruntergeladen nach: $LOCAL_DIR/$LATEST"

Troubleshooting

Verbindungsprobleme

Problem: mc: <ERROR> Unable to initialize new alias

Lösung: 

# Endpoint URL prüfen (https:// erforderlich)
mc alias set ayedo-backup https://backup.ayedo.cloud ... ...

# Netzwerkverbindung testen
curl -I https://backup.ayedo.cloud

Zugriff verweigert

Problem: Access Denied

Lösung: 

# Credentials prüfen
mc alias list ayedo-backup

# Alias neu konfigurieren
mc alias remove ayedo-backup
mc alias set ayedo-backup https://... ACCESS_KEY SECRET_KEY

Backup nicht gefunden

Problem: Backup-Verzeichnis ist leer

Lösung: 

# Pfad überprüfen
mc ls ayedo-backup/

# Alle Verzeichnisse durchsuchen
mc find ayedo-backup/ --name "backup_manifest"

Langsamer Download

Problem: Download ist sehr langsam

Lösung: 

# Parallele Downloads aktivieren (Standard: 4)
mc cp --recursive --parallel 8 <src> <dst>

# Oder: Mirror-Befehl für effizienteres Kopieren
mc mirror my-db-backups/mydb-cnpg-a1b2c3d4e5f6/mydb/ ~/backups/mydb/

Best Practices

Regelmäßige Backup-Überprüfung

  1. Wöchentliche Überprüfung: Prüfen Sie, ob aktuelle Backups vorhanden sind
  2. Monatliche Test-Restores: Führen Sie regelmäßig Test-Wiederherstellungen durch
  3. Dokumentation: Dokumentieren Sie Ihre Backup/Restore-Prozeduren

Sicherheit

  1. Credentials sicher aufbewahren: Nutzen Sie einen Password Manager
  2. Temporäre Credentials: Fordern Sie zeitlich begrenzte Zugangsdaten an
  3. Lokale Backups verschlüsseln: Verschlüsseln Sie heruntergeladene Backups
# Heruntergeladenes Backup verschlüsseln
gpg --symmetric --cipher-algo AES256 ~/backups/mydb/20250103T020000.tar.gz

Speichermanagement

  1. Alte lokale Backups löschen: Behalten Sie nur benötigte Backups lokal
  2. Komprimierung nutzen: Backups sind bereits komprimiert, vermeiden Sie doppelte Komprimierung

Weiterführende Ressourcen

Support

Bei Fragen zu Backups oder Zugriffsproblemen: