Zarządzanie kopiami zapasowymi

Dokumentacja dla administratorów systemu Ready4Docs

Ostatnia aktualizacja: 2025-12-28

Spis treści

1. Przegląd systemu backupu
2. Konfiguracja
3. Harmonogram automatyczny
4. Ręczne zarządzanie
5. Przywracanie z backupu
6. Monitorowanie
7. Rozwiązywanie problemów

---

Przegląd systemu backupu

Architektura

┌─────────────────────────────────────────────────────────────────┐
│                     System Backup Ready4Docs                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────────┐   │
│  │   PostgreSQL │───▶│  pg_dump     │───▶│  /home/ready4docs │   │
│  │   (Docker)   │    │  (gzip)      │    │  /backup/db/      │   │
│  └──────────────┘    └──────────────┘    └──────────────────┘   │
│                                                                  │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────────┐   │
│  │   .env       │───▶│  cp          │───▶│  /home/ready4docs │   │
│  │   configs    │    │              │    │  /backup/config/  │   │
│  └──────────────┘    └──────────────┘    └──────────────────┘   │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │  Systemd Timers:                                          │   │
│  │  • ready4docs-backup.timer         → 03:00 daily          │   │
│  │  • ready4docs-backup-cleanup.timer → 04:00 daily (30 dni) │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Co jest backupowane

Element	Lokalizacja źródłowa	Częstotliwość	Retencja
Baza danych PostgreSQL	Docker: ready4docs-db	Codziennie 03:00	30 dni
Konfiguracja .env	/home/ready4docs/public_html/backend/.env	Codziennie 03:00	30 dni

Lokalizacja backupów

/home/ready4docs/backup/
├── db/                          # Backupy bazy danych
│   ├── ready4docs_20251228_030000.sql.gz
│   ├── ready4docs_20251227_030000.sql.gz
│   └── ...
├── config/                      # Backupy konfiguracji
│   ├── backend.env.20251228_030000
│   └── ...
├── full/                        # Pełne backupy (ręczne)
├── weekly/                      # Backupy tygodniowe
├── monthly/                     # Backupy miesięczne
└── temp/                        # Pliki tymczasowe

---

Konfiguracja

Pliki konfiguracyjne

Plik	Opis
/home/ready4docs/public_html/scripts/backup.sh	Główny skrypt backupu
/home/ready4docs/public_html/backend/config/backup.php	Konfiguracja Laravel
/etc/systemd/system/ready4docs-backup.service	Usługa systemd
/etc/systemd/system/ready4docs-backup.timer	Timer systemd

Zmienne środowiskowe

Skrypt backup.sh odczytuje ustawienia z /home/ready4docs/public_html/backend/.env:

# Opcjonalne nadpisanie w środowisku
BACKUP_ROOT=/home/ready4docs/backup     # Katalog backupów
DB_CONTAINER=ready4docs-db              # Nazwa kontenera Docker
DB_NAME=ready4docs                      # Nazwa bazy
DB_USER=ready4docs                      # Użytkownik bazy
DB_HOST=127.0.0.1                       # Host bazy
DB_PORT=5433                            # Port bazy

Konfiguracja retencji

Edytuj /home/ready4docs/public_html/backend/config/backup.php:

return [
    'retention_days' => env('BACKUP_RETENTION_DAYS', 30),  // Dni przechowywania
    'max_backups' => env('BACKUP_MAX_COUNT', 10),          // Max liczba backupów
    'compress' => env('BACKUP_COMPRESS', true),            // Kompresja gzip
];

---

Harmonogram automatyczny

Aktywne timery

# Sprawdź status timerów
sudo systemctl list-timers | grep ready4docs

Timer	Godzina	Opis
ready4docs-backup.timer	03:00	Backup bazy danych i konfiguracji
ready4docs-backup-cleanup.timer	04:00	Usuwanie backupów starszych niż 30 dni

Zarządzanie harmonogramem

# Włącz automatyczne backupy
sudo systemctl enable ready4docs-backup.timer
sudo systemctl start ready4docs-backup.timer

# Wyłącz automatyczne backupy
sudo systemctl stop ready4docs-backup.timer
sudo systemctl disable ready4docs-backup.timer

# Zmień godzinę backupu (edytuj timer)
sudo systemctl edit ready4docs-backup.timer

Przykład zmiany godziny na 02:00:

[Timer]
OnCalendar=*-*-* 02:00:00

Po edycji:

sudo systemctl daemon-reload
sudo systemctl restart ready4docs-backup.timer

---

Ręczne zarządzanie

Wykonaj backup teraz

# Uruchom backup natychmiast
sudo systemctl start ready4docs-backup.service

# Lub bezpośrednio skryptem
BACKUP_ROOT=/home/ready4docs/backup /home/ready4docs/public_html/scripts/backup.sh

Lista backupów

# Pokaż wszystkie backupy bazy danych
ls -lah /home/ready4docs/backup/db/

# Pokaż 10 najnowszych
ls -lt /home/ready4docs/backup/db/*.sql.gz | head -10

# Rozmiar całkowity backupów
du -sh /home/ready4docs/backup/

Usuń stare backupy ręcznie

# Usuń backupy starsze niż 7 dni
find /home/ready4docs/backup/db -name "*.sql.gz" -mtime +7 -delete

# Usuń konkretny backup
rm /home/ready4docs/backup/db/ready4docs_20251225_030000.sql.gz

Skopiuj backup na zewnętrzny serwer

# SCP do zdalnego serwera
scp /home/ready4docs/backup/db/ready4docs_20251228_*.sql.gz user@backup-server:/backups/

# Rsync (dla regularnej synchronizacji)
rsync -avz /home/ready4docs/backup/ user@backup-server:/backups/ready4docs/

---

Przywracanie z backupu

⚠️ UWAGA

Przywracanie nadpisuje wszystkie dane w bazie!

Przed przywróceniem:

1. Upewnij się, że masz backup aktualnych danych
2. Poinformuj użytkowników o planowanej przerwie
3. Zatrzymaj aplikację

Procedura przywracania

1. Zatrzymaj aplikację

# Zatrzymaj PHP-FPM i kolejki
sudo systemctl stop php8.4-fpm
sudo docker stop readynextos-queue readynextos-reverb

2. Wybierz backup do przywrócenia

# Lista dostępnych backupów
ls -lt /home/ready4docs/backup/db/*.sql.gz

# Sprawdź rozmiar i datę
ls -lah /home/ready4docs/backup/db/ready4docs_20251228_030000.sql.gz

3. Przywróć bazę danych

# Metoda 1: Przywrócenie z kompresji (zalecane)
gunzip -c /home/ready4docs/backup/db/ready4docs_20251228_030000.sql.gz | \
  docker exec -i ready4docs-db psql -U ready4docs ready4docs

# Metoda 2: Rozpakuj najpierw, potem przywróć
gunzip -k /home/ready4docs/backup/db/ready4docs_20251228_030000.sql.gz
docker exec -i ready4docs-db psql -U ready4docs ready4docs < \
  /home/ready4docs/backup/db/ready4docs_20251228_030000.sql

4. Weryfikacja

# Sprawdź czy baza działa
docker exec ready4docs-db psql -U ready4docs -c "SELECT COUNT(*) FROM users;"

# Sprawdź integralność
cd /home/ready4docs/public_html/backend
php artisan tinker --execute="echo 'Users: ' . \App\Models\User::count();"

5. Uruchom aplikację

# Uruchom usługi
sudo systemctl start php8.4-fpm
sudo docker start readynextos-queue readynextos-reverb

# Wyczyść cache
cd /home/ready4docs/public_html/backend
php artisan cache:clear
php artisan config:clear

Przywracanie pojedynczej tabeli

# 1. Rozpakuj backup
gunzip -k /home/ready4docs/backup/db/ready4docs_20251228_030000.sql.gz

# 2. Wyodrębnij tabelę (np. users)
grep -A 10000 "COPY public.users" ready4docs_20251228_030000.sql | \
  grep -m 1 -B 10000 "^\\\." > users_only.sql

# 3. Przywróć tylko tę tabelę
docker exec -i ready4docs-db psql -U ready4docs ready4docs < users_only.sql

Przywracanie do innej bazy (testowej)

# 1. Utwórz testową bazę
docker exec ready4docs-db psql -U ready4docs -c "CREATE DATABASE ready4docs_test;"

# 2. Przywróć do testowej bazy
gunzip -c /home/ready4docs/backup/db/ready4docs_20251228_030000.sql.gz | \
  docker exec -i ready4docs-db psql -U ready4docs ready4docs_test

# 3. Po testach usuń
docker exec ready4docs-db psql -U ready4docs -c "DROP DATABASE ready4docs_test;"

---

Monitorowanie

Sprawdź status ostatniego backupu

# Logi ostatniego backupu
journalctl -u ready4docs-backup.service -n 50

# Status usługi
sudo systemctl status ready4docs-backup.service

Sprawdź czy backup się wykonał

# Sprawdź czy dzisiejszy backup istnieje
TODAY=$(date +%Y%m%d)
ls -la /home/ready4docs/backup/db/*${TODAY}*.sql.gz

# Jeśli brak - sprawdź logi błędów
journalctl -u ready4docs-backup.service --since today

Alerty (opcjonalne)

Dodaj do /home/ready4docs/public_html/scripts/backup.sh na końcu:

# Wyślij powiadomienie email po backupie
BACKUP_FILE=$(ls -t /home/ready4docs/backup/db/*.sql.gz | head -1)
BACKUP_SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
echo "Backup completed: $BACKUP_FILE ($BACKUP_SIZE)" | \
  mail -s "Ready4Docs Backup OK" admin@example.com

---

Rozwiązywanie problemów

Backup nie wykonuje się

# 1. Sprawdź czy timer jest aktywny
sudo systemctl status ready4docs-backup.timer

# 2. Sprawdź logi
journalctl -u ready4docs-backup.service -n 100

# 3. Uruchom ręcznie z debugowaniem
BACKUP_ROOT=/home/ready4docs/backup bash -x /home/ready4docs/public_html/scripts/backup.sh

Błąd połączenia z bazą

# Sprawdź czy kontener działa
docker ps | grep ready4docs-db

# Sprawdź połączenie
docker exec ready4docs-db pg_isready -U ready4docs

# Restart kontenera
docker restart ready4docs-db

Brak miejsca na dysku

# Sprawdź miejsce
df -h /home/ready4docs/backup

# Usuń stare backupy
find /home/ready4docs/backup/db -name "*.sql.gz" -mtime +7 -delete

# Sprawdź największe pliki
du -sh /home/ready4docs/backup/db/* | sort -rh | head -10

Uszkodzony backup

# Sprawdź integralność gzip
gzip -t /home/ready4docs/backup/db/ready4docs_20251228_030000.sql.gz
echo $?  # 0 = OK, 1 = uszkodzony

# Jeśli uszkodzony - użyj poprzedniego backupu
ls -lt /home/ready4docs/backup/db/*.sql.gz | head -5

Przywracanie po awarii bazy (WAL corruption)

Jeśli baza danych uległa uszkodzeniu (np. błędy WAL):

# 1. Zatrzymaj kontener
docker stop ready4docs-db

# 2. Usuń uszkodzone dane (UWAGA: nieodwracalne!)
sudo rm -rf /home/ready4docs/postgres-data/data/pgdata/*

# 3. Uruchom kontener (utworzy nową bazę)
docker start ready4docs-db
sleep 10

# 4. Przywróć z ostatniego backupu
gunzip -c /home/ready4docs/backup/db/OSTATNI_BACKUP.sql.gz | \
  docker exec -i ready4docs-db psql -U ready4docs ready4docs

# 5. Uruchom migracje
cd /home/ready4docs/public_html/backend
php artisan migrate --force

---

Checklist administratora

Codzienny

• Sprawdź czy backup z poprzedniej nocy istnieje
• Sprawdź logi błędów: journalctl -u ready4docs-backup.service --since yesterday

Tygodniowy

• Sprawdź miejsce na dysku: df -h /home/ready4docs/backup
• Zweryfikuj losowy backup: gzip -t /home/ready4docs/backup/db/PLIK.sql.gz
• Skopiuj najnowszy backup na zewnętrzny serwer

Miesięczny

• Wykonaj test przywracania do testowej bazy
• Przejrzyj retencję i usuń niepotrzebne backupy
• Zaktualizuj dokumentację jeśli zmieniła się konfiguracja

---

Kontakt

W przypadku problemów z backupami:

1. Sprawdź tę dokumentację
2. Przejrzyj logi: journalctl -u ready4docs-backup.service
3. Skontaktuj się z zespołem DevOps