Konfiguruj zaplanowane automatyczne kopie zapasowe PostgreSQL dla IBM Bob i zarządzaj nimi, w tym wyrażenia cron, zasady retencji, zawieszanie i wznawianie oraz monitorowanie.

Zaplanowane kopie zapasowe automatyzują ochronę bazy danych i zmniejszają ryzyko utraty danych. IBM Bob używa Kubernetes CronJobs do wykonywania kopii zapasowych zgodnie z harmonogramem zdefiniowanym w konfiguracji kopii zapasowych.

Uwaga:

Domyślnie kopie zapasowe są uruchamiane przy użyciu uniwersalnego czasu koordynowanego (UTC).

Konfiguracja harmonogramów kopii zapasowych

Skonfiguruj harmonogram kopii zapasowych, aktualizując pole schedule w ConfigMap konfiguracji kopii zapasowych. Wartość używa standardowej składni cron i określa, jak często uruchamiane są zadania tworzenia kopii zapasowych.

apiVersion: v1
kind: ConfigMap
metadata:
  name: bob-postgres-backup-config
  namespace: <bob-instance-namespace>
  labels:
    bob.ibm.com/backup-config: "true"
data:
  config.yaml: |
    # Harmonogram kopii zapasowych w formacie cron (strefa czasowa UTC)
    schedule: "0 2 * * *"  # Codziennie o 2:00 UTC

    # ... pozostała konfiguracja ...

Zrozumienie składni cron

Harmonogramy cron składają się z pięciu pól definiujących częstotliwość wykonywania.

Pole	Wartości	Znaki specjalne
Minuta	0–59	`*`, `,`, `-`, `/`
Godzina	0–23	`*`, `,`, `-`, `/`
Dzień	1–31	`*`, `,`, `-`, `/`
Miesiąc	1–12	`*`, `,`, `-`, `/`
Dzień tygodnia	0–7 (`0` i `7` oznaczają niedzielę)	`*`, `,`, `-`, `/`

Wybierz harmonogram zgodny z celami punktu przywracania (RPO) i wymaganiami biznesowymi.

Kwestie do rozważenia przy planowaniu

Strefa czasowa (UTC)

Wszystkie harmonogramy działają w strefie czasowej UTC. Planuj harmonogramy według czasu UTC, a nie czasu lokalnego. Na przykład:

0 2 * * * = 2:00 UTC = 4:00 CEST (czas letni) lub 3:00 CET (czas zimowy)

Równoczesne kopie zapasowe

Wszystkie skonfigurowane klastry wykonują kopię zapasową jednocześnie według tego samego harmonogramu. Zwiększa to obciążenie I/O pamięci masowej i dzieli przepustowość sieci między wszystkie kopie zapasowe. Aby rozłożyć kopie zapasowe w środowiskach o ograniczonych zasobach, utwórz wiele obiektów ConfigMap z różnymi harmonogramami:

# ConfigMap 1: bob-db o 2:00
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: bob-db-backup-config
  labels:
    bob.ibm.com/backup-config: "true"
data:
  config.yaml: |
    schedule: "0 2 * * *"
    clusters:
      - name: bob-db
        database: bob
        secretName: bob-db-app
---
# ConfigMap 2: keycloak-db o 3:00
apiVersion: v1
kind: ConfigMap
metadata:
  name: keycloak-db-backup-config
  labels:
    bob.ibm.com/backup-config: "true"
data:
  config.yaml: |
    schedule: "0 3 * * *"
    clusters:
      - name: bob-keycloak-db
        database: app
        secretName: bob-keycloak-db-app

Czas trwania kopii zapasowej

Weź pod uwagę rozmiar bazy danych podczas planowania, aby uniknąć nakładania się uruchomień kopii zapasowych.

Rozmiar bazy danych	Oczekiwany czas trwania
Poniżej 1 GB	1–5 minut
1–5 GB	5–15 minut
5–20 GB	15–45 minut
20–50 GB	45–120 minut
Powyżej 50 GB	2+ godziny

Godziny poza szczytem

Planuj kopie zapasowe w okresach niskiego wykorzystania. Unikaj godzin szczytu biznesowego i monitoruj wydajność bazy danych podczas tworzenia kopii zapasowych.

Zmiana harmonogramu

Aby zaktualizować harmonogram kopii zapasowych, zmodyfikuj ConfigMap kopii zapasowej:

oc edit configmap bob-postgres-backup-config -n <bob-instance-namespace>

Zaktualizuj pole schedule i zapisz. Kontroler automatycznie wykrywa zmianę i aktualizuje CronJobs.

Sprawdź zaktualizowany harmonogram:

oc get cronjob bob-db-backup-cronjob -n <bob-instance-namespace> -o jsonpath='{.spec.schedule}'

Zawieszanie i wznawianie kopii zapasowych

Jeśli chcesz wstrzymać tworzenie kopii zapasowych podczas prac konserwacyjnych bez usuwania konfiguracji kopii zapasowych, zawiéś kopie zapasowe w zasobie niestandardowym Bob:

oc patch bob bob-instance -n <bob-instance-namespace> --type=merge \
  -p '{"spec":{"postgresBackup":{"suspend":true}}}'

Zawieszenie kopii zapasowych zachowuje wszystkie istniejące zasoby kopii zapasowych, zapobiegając jednocześnie uruchamianiu nowych zadań.

Sprawdź, czy obiekty CronJobs są zawieszone:

oc get cronjobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup
# Kolumna SUSPEND powinna pokazywać "True"

Wznów kopie zapasowe po zakończeniu konserwacji:

oc patch bob bob-instance -n <bob-instance-namespace> --type=merge \
  -p '{"spec":{"postgresBackup":{"suspend":false}}}'

Monitorowanie aktywności kopii zapasowych

Regularne monitorowanie pomaga upewnić się, że zadania tworzenia kopii zapasowych nadal działają pomyślnie i że cele odzyskiwania mogą zostać osiągnięte.

# Wyświetl listę ostatnich zadań kopii zapasowych
oc get jobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup \
  --sort-by=.metadata.creationTimestamp

# Sprawdź status CronJob
oc get cronjobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup

# Wyświetl ostatni zaplanowany czas
oc get cronjob bob-db-backup-cronjob -n <bob-instance-namespace> \
  -o jsonpath='{.status.lastScheduleTime}'

# Wyświetl dzienniki kopii zapasowej
oc logs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup --tail=100

Niezwłocznie badaj awarie, aby zapobiec lukom w ochronie kopii zapasowych.

Zarządzanie retencją kopii zapasowych

Zasady retencji określają, ile kopii zapasowych jest przechowywanych przed automatycznym usunięciem starszych kopii zapasowych.

data:
  config.yaml: |
    # Liczba kopii zapasowych do zachowania na klaster
    retention: 7  # Zachowaj ostatnie 7 kopii zapasowych

Wyższe wartości retencji zwiększają elastyczność odzyskiwania, ale wymagają dodatkowej pamięci masowej.

Zachowanie retencji:

Najstarsze kopie zapasowe są automatycznie usuwane po każdej udanej kopii zapasowej.

Retencja jest określana na klaster — każdy klaster utrzymuje własną liczbę.

Czyszczenie odbywa się natychmiast po utworzeniu kopii zapasowej.

Na przykład przy retention: 7:

Dni 1–7: Zgromadzenie 7 kopii zapasowych.

Dzień 8: Utworzenie nowej kopii zapasowej, usunięcie kopii zapasowej z dnia 1.

Dzień 9: Utworzenie nowej kopii zapasowej, usunięcie kopii zapasowej z dnia 2.

Uruchamianie ręcznej kopii zapasowej

Aby ręcznie uruchomić kopię zapasową poza harmonogramem:

# Utwórz zadanie z CronJob
oc create job --from=cronjob/bob-db-backup-cronjob \
  manual-backup-$(date +%s) -n <bob-instance-namespace>

# Monitoruj zadanie
oc get jobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup

# Wyświetl dzienniki zadania
oc logs -n <bob-instance-namespace> job/manual-backup-<timestamp>

Najlepsze praktyki

Planuj kopie zapasowe w godzinach poza szczytem (zwykle 2:00–4:00 czasu lokalnego).

Używaj spójnego harmonogramu dla przewidywalności.

Pamiętaj o strefie czasowej UTC podczas ustawiania harmonogramów.

Rozłóż kopie zapasowe w czasie, jeśli zasoby są ograniczone.

Regularnie monitoruj sukces kopii zapasowych.

Testuj procedury przywracania co miesiąc.

Dokumentuj harmonogram i jego uzasadnienie.

Skonfiguruj alerty o niepowodzeniach kopii zapasowych.

Planowanie kopii zapasowych