Backup i przywracanie Uptime Kuma — kompletny przewodnik

Dlaczego backup monitoringu jest krytyczny

System monitoringu to Twoje oczy i uszy w infrastrukturze IT. Gdy Uptime Kuma przestaje działać lub traci dane, nie tylko tracisz historię dostępności — tracisz zdolność wykrywania awarii w czasie rzeczywistym. A to oznacza, że Twoje strony, API i serwery mogą leżeć, a Ty o tym nie wiesz.

Wyobraź sobie scenariusz: dysk serwera ulega awarii w piątek wieczorem. Twoja instancja Uptime Kuma — z kilkudziesięcioma skonfigurowanymi monitorami, powiadomieniami na Telegram i Discord, stronami statusu dla klientów i miesięczną historią uptime — znika w jednej chwili. Bez backupu odbudowa tej konfiguracji od zera zajmie godziny, a historyczne dane o dostępności (potrzebne do raportów SLA) są stracone bezpowrotnie.

Kluczowe powody, dla których backup Uptime Kuma jest niezbędny:

• Ochrona konfiguracji — monitory, powiadomienia, strony statusu, tagi, grupy, maintenance windows — to wszystko wymaga czasu i staranności przy konfiguracji
• Zachowanie historii — dane heartbeatów, historia uptime/downtime, czasy odpowiedzi — kluczowe dla raportów SLA i analizy trendów
• Ciągłość monitoringu — szybkie przywrócenie oznacza minuty bez nadzoru, nie godziny czy dni
• Migracja i skalowanie — przeniesienie instancji na mocniejszy serwer, do innego dostawcy lub między środowiskami (dev → prod)
• Ochrona przed błędami ludzkimi — przypadkowe usunięcie monitorów, nieudana aktualizacja, błąd w konfiguracji — backup pozwala cofnąć się w czasie

Co przechowuje Uptime Kuma — anatomia danych

Zanim przejdziemy do metod backupu, musisz dokładnie wiedzieć, jakie dane przechowuje Uptime Kuma i gdzie się one znajdują. To kluczowe, aby backup był kompletny i przywracanie przebiegło bez problemów.

Główny katalog danych

Wszystkie dane Uptime Kuma znajdują się w jednym katalogu — domyślnie jest to ./data/ względem katalogu instalacji (bare metal) lub wolumen Docker zamontowany jako /app/data w kontenerze. Oto struktura tego katalogu:

data/
├── kuma.db              # Główna baza danych SQLite
├── kuma.db-wal          # Write-Ahead Log (WAL) SQLite
├── kuma.db-shm          # Shared memory file SQLite
├── upload/              # Przesłane pliki (favicony, logo stron statusu)
│   └── logo*.png
└── screenshots/         # Zrzuty ekranu z monitorów Real Browser (Chromium)
    └── *.png

Baza danych SQLite (kuma.db)

To serce Uptime Kuma — pojedynczy plik SQLite zawierający absolutnie wszystko:

Pliki WAL i SHM

Pliki kuma.db-wal (Write-Ahead Log) i kuma.db-shm (Shared Memory) to integralne części bazy SQLite w trybie WAL. Zawierają niezacommitowane transakcje — jeśli skopiujesz tylko kuma.db bez tych plików, możesz stracić ostatnie dane. Dlatego przy backupie musisz uwzględnić wszystkie trzy pliki lub użyć komendy .backup w sqlite3, która tworzy spójną kopię.

Backup ręczny — kopiowanie plików i dump SQLite

Najprostszą metodą backupu jest ręczne skopiowanie danych. To dobry punkt wyjścia i warto zrozumieć ten proces, zanim przejdziesz do automatyzacji.

Metoda 1: Kopiowanie plików (z zatrzymaniem aplikacji)

Najbezpieczniejsza metoda ręczna — zatrzymujesz Uptime Kuma, kopiujesz pliki, uruchamiasz ponownie. Gwarantuje to spójność danych, bo żaden proces nie zapisuje do bazy podczas kopiowania.

Dla instalacji bare metal:

# Zatrzymaj Uptime Kuma
pm2 stop uptime-kuma
# lub: systemctl stop uptime-kuma

# Skopiuj cały katalog data
cp -r /opt/uptime-kuma/data /backup/uptime-kuma-$(date +%Y%m%d-%H%M%S)

# Uruchom ponownie
pm2 start uptime-kuma
# lub: systemctl start uptime-kuma

Dla instalacji Docker:

# Zatrzymaj kontener
docker stop uptime-kuma

# Skopiuj wolumen (jeśli bind mount)
cp -r /srv/uptime-kuma/data /backup/uptime-kuma-$(date +%Y%m%d-%H%M%S)

# Uruchom ponownie
docker start uptime-kuma

Metoda 2: SQLite dump (bez przestoju)

Komenda sqlite3 .backup tworzy spójną kopię bazy danych nawet gdy Uptime Kuma działa. To rekomendowana metoda dla środowisk, w których każda minuta monitoringu jest ważna.

# Spójny dump bazy danych (bez zatrzymywania Uptime Kuma)
sqlite3 /opt/uptime-kuma/data/kuma.db ".backup '/backup/kuma-$(date +%Y%m%d-%H%M%S).db'"

# Alternatywnie — eksport do SQL (czytelny tekstowo)
sqlite3 /opt/uptime-kuma/data/kuma.db .dump > /backup/kuma-$(date +%Y%m%d-%H%M%S).sql

Pamiętaj, że dump bazy to nie wszystko — musisz też skopiować katalogi upload/ i screenshots/:

# Kompletny backup: baza + pliki
BACKUP_DIR="/backup/uptime-kuma-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"

# Dump bazy SQLite (spójny, bez przestoju)
sqlite3 /opt/uptime-kuma/data/kuma.db ".backup '$BACKUP_DIR/kuma.db'"

# Kopiuj dodatkowe pliki
cp -r /opt/uptime-kuma/data/upload "$BACKUP_DIR/" 2>/dev/null
cp -r /opt/uptime-kuma/data/screenshots "$BACKUP_DIR/" 2>/dev/null

# Opcjonalnie: spakuj
tar -czf "$BACKUP_DIR.tar.gz" -C /backup "$(basename $BACKUP_DIR)"
rm -rf "$BACKUP_DIR"

echo "Backup zapisany: $BACKUP_DIR.tar.gz"

Metoda 3: Export z poziomu GUI

Uptime Kuma oferuje wbudowaną funkcję eksportu konfiguracji z poziomu interfejsu webowego. Przejdź do Settings → Backup i kliknij Export. Pobierzesz plik JSON z konfiguracją monitorów, powiadomień i stron statusu.

Ważne ograniczenia eksportu JSON:

• Eksportuje tylko konfigurację — nie zawiera historii heartbeatów
• Nie zawiera danych użytkowników ani haseł
• Nie zawiera przesłanych plików (logo, favicony)
• Idealny jako uzupełnienie pełnego backupu, nie jako jedyna metoda

Funkcja importu (Settings → Backup → Import) pozwala wczytać taki plik JSON do nowej lub istniejącej instancji — przydatne do szybkiego odtworzenia konfiguracji monitorów.

Automatyczny backup — skrypty i cron

Ręczny backup jest dobry na start, ale w produkcji musisz go zautomatyzować. Najprościej to zrobić za pomocą skryptu bash i crona.

Skrypt backup — kompletny przykład

Poniższy skrypt tworzy spójny backup bazy SQLite, kopiuje dodatkowe pliki, pakuje archiwum i stosuje politykę retencji (usuwa stare kopie):

#!/bin/bash
# uptime-kuma-backup.sh — automatyczny backup Uptime Kuma
# Użycie: dodaj do crontab lub uruchom ręcznie

# === KONFIGURACJA ===
DATA_DIR="/opt/uptime-kuma/data"       # Katalog danych Uptime Kuma
BACKUP_DIR="/backup/uptime-kuma"       # Katalog docelowy backupów
RETENTION_DAYS=30                       # Ile dni trzymać stare backupy
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_NAME="uk-backup-$DATE"
BACKUP_PATH="$BACKUP_DIR/$BACKUP_NAME"

# === TWORZENIE BACKUPU ===
mkdir -p "$BACKUP_PATH"

# 1. Spójny dump bazy SQLite (bez przestoju)
if [ -f "$DATA_DIR/kuma.db" ]; then
    sqlite3 "$DATA_DIR/kuma.db" ".backup '$BACKUP_PATH/kuma.db'"
    echo "[OK] Baza danych skopiowana"
else
    echo "[BŁĄD] Nie znaleziono kuma.db w $DATA_DIR"
    exit 1
fi

# 2. Kopiuj pliki statyczne
cp -r "$DATA_DIR/upload" "$BACKUP_PATH/" 2>/dev/null
cp -r "$DATA_DIR/screenshots" "$BACKUP_PATH/" 2>/dev/null
echo "[OK] Pliki statyczne skopiowane"

# 3. Pakuj archiwum
tar -czf "$BACKUP_DIR/$BACKUP_NAME.tar.gz" -C "$BACKUP_DIR" "$BACKUP_NAME"
rm -rf "$BACKUP_PATH"
echo "[OK] Archiwum: $BACKUP_DIR/$BACKUP_NAME.tar.gz"

# 4. Rozmiar backupu
SIZE=$(du -h "$BACKUP_DIR/$BACKUP_NAME.tar.gz" | cut -f1)
echo "[INFO] Rozmiar backupu: $SIZE"

# === RETENCJA — usuwanie starych backupów ===
find "$BACKUP_DIR" -name "uk-backup-*.tar.gz" -mtime +$RETENTION_DAYS -delete
DELETED=$(find "$BACKUP_DIR" -name "uk-backup-*.tar.gz" -mtime +$RETENTION_DAYS 2>/dev/null | wc -l)
echo "[OK] Retencja: usunięto $DELETED starych backupów (starszych niż $RETENTION_DAYS dni)"

echo "[GOTOWE] Backup Uptime Kuma zakończony: $DATE"

Konfiguracja cron

Dodaj skrypt do crontab, aby backup wykonywał się automatycznie:

# Edytuj crontab
crontab -e

# Backup codziennie o 3:00 w nocy
0 3 * * * /usr/local/bin/uptime-kuma-backup.sh >> /var/log/uk-backup.log 2>&1

# Alternatywnie: co 6 godzin (dla krytycznych instalacji)
0 */6 * * * /usr/local/bin/uptime-kuma-backup.sh >> /var/log/uk-backup.log 2>&1

Nie zapomnij nadać uprawnień do wykonywania:

chmod +x /usr/local/bin/uptime-kuma-backup.sh

Powiadomienie o statusie backupu

Warto dodać powiadomienie o wyniku backupu — np. na Telegram lub do logu systemowego. Możesz też połączyć to z Push monitorem w samej Uptime Kuma — jeśli backup się nie wykona, monitor przejdzie w stan DOWN:

# Na końcu skryptu backup dodaj:
# Powiadomienie Push do Uptime Kuma (monitor typu Push)
PUSH_URL="https://twoja-instancja.uptimekuma.eu/api/push/TWOJ_TOKEN"
curl -s "$PUSH_URL?status=up&msg=Backup+OK:+$SIZE" > /dev/null

# Opcjonalnie: powiadomienie na Telegram
# TELEGRAM_BOT_TOKEN="123456:ABC..."
# TELEGRAM_CHAT_ID="987654321"
# curl -s "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
#   -d "chat_id=$TELEGRAM_CHAT_ID" \
#   -d "text=✅ Backup Uptime Kuma OK: $SIZE ($DATE)" > /dev/null

Backup wolumenów Docker

Większość instalacji Uptime Kuma działa w Dockerze, dlatego warto znać specyficzne metody backupu wolumenów Docker. Podejście zależy od tego, czy używasz named volume czy bind mount.

Bind mount — najprostszy scenariusz

Jeśli w docker-compose.yml masz bind mount (np. ./data:/app/data), Twoje dane leżą bezpośrednio na hoście i możesz je backupować jak zwykłe pliki — wszystkie metody z poprzedniej sekcji działają bez zmian.

# Typowy docker-compose.yml z bind mount
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    volumes:
      - ./data:/app/data    # Bind mount — dane na hoście
    ports:
      - "3001:3001"
    restart: unless-stopped

Named volume — backup przez kontener pomocniczy

Jeśli używasz named volume (np. uptime-kuma-data:/app/data), dane nie leżą w czytelnym katalogu na hoście. Musisz użyć kontenera pomocniczego, który zamontuje wolumen i skopiuje dane:

# Backup named volume do archiwum tar.gz
docker run --rm \
  -v uptime-kuma-data:/source:ro \
  -v /backup:/target \
  alpine tar -czf /target/uk-volume-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Polecenie tworzy tymczasowy kontener Alpine, montuje wolumen Uptime Kuma jako /source (read-only), a katalog backupu na hoście jako /target, i pakuje zawartość wolumenu do archiwum.

Backup z docker-compose (zatrzymanie i kopia)

Dla maksymalnej spójności możesz zatrzymać cały stos, wykonać backup i uruchomić ponownie:

# W katalogu z docker-compose.yml
cd /opt/uptime-kuma

# Zatrzymaj kontener
docker compose stop

# Backup wolumenu
docker run --rm \
  -v uptime-kuma-data:/source:ro \
  -v /backup:/target \
  alpine tar -czf /target/uk-backup-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

# Uruchom ponownie
docker compose start

SQLite dump w działającym kontenerze

Jeśli nie chcesz zatrzymywać kontenera, możesz wykonać dump SQLite bezpośrednio wewnątrz kontenera Uptime Kuma:

# Dump bazy wewnątrz kontenera
docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup '/app/data/kuma-backup.db'"

# Skopiuj backup z kontenera na hosta
docker cp uptime-kuma:/app/data/kuma-backup.db /backup/kuma-$(date +%Y%m%d).db

# Usuń tymczasowy plik z kontenera
docker exec uptime-kuma rm /app/data/kuma-backup.db

Kompletny skrypt backup Docker

Poniżej gotowy skrypt do automatycznego backupu Uptime Kuma w Dockerze (named volume), z retencją i kompresją:

#!/bin/bash
# uk-docker-backup.sh — backup Uptime Kuma z Docker named volume

CONTAINER="uptime-kuma"
VOLUME="uptime-kuma-data"
BACKUP_DIR="/backup/uptime-kuma"
RETENTION_DAYS=30
DATE=$(date +%Y%m%d-%H%M%S)

mkdir -p "$BACKUP_DIR"

# Spójny dump SQLite wewnątrz kontenera
docker exec "$CONTAINER" sqlite3 /app/data/kuma.db \
  ".backup '/app/data/kuma-backup-temp.db'"

# Backup całego wolumenu (z dumpem zamiast oryginalnej bazy)
docker run --rm \
  -v "$VOLUME":/source:ro \
  -v "$BACKUP_DIR":/target \
  alpine tar -czf "/target/uk-backup-$DATE.tar.gz" -C /source .

# Usuń tymczasowy dump
docker exec "$CONTAINER" rm -f /app/data/kuma-backup-temp.db

# Retencja
find "$BACKUP_DIR" -name "uk-backup-*.tar.gz" -mtime +"$RETENTION_DAYS" -delete

echo "[OK] Backup: $BACKUP_DIR/uk-backup-$DATE.tar.gz"

Backup z MariaDB/MySQL (wersja 2.x)

Od wersji 2.0 Uptime Kuma obsługuje MariaDB i MySQL jako alternatywę dla SQLite. Jeśli korzystasz z tej konfiguracji (zalecane dla większych wdrożeń z ponad 500 monitorami), backup bazy danych wymaga innego podejścia.

Typowa konfiguracja docker-compose z MariaDB

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"
    environment:
      - UPTIME_KUMA_DB_TYPE=mariadb
      - UPTIME_KUMA_DB_HOSTNAME=db
      - UPTIME_KUMA_DB_PORT=3306
      - UPTIME_KUMA_DB_NAME=uptimekuma
      - UPTIME_KUMA_DB_USERNAME=uptimekuma
      - UPTIME_KUMA_DB_PASSWORD=silne_haslo
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mariadb:11
    volumes:
      - db-data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root_haslo
      - MYSQL_DATABASE=uptimekuma
      - MYSQL_USER=uptimekuma
      - MYSQL_PASSWORD=silne_haslo
    restart: unless-stopped

volumes:
  db-data:

Backup z mysqldump

Narzędzie mysqldump tworzy spójny dump bazy danych w formacie SQL. To standardowa i sprawdzona metoda backupu dla MariaDB/MySQL:

# Dump bazy z kontenera MariaDB
docker exec db mysqldump -u uptimekuma -p'silne_haslo' \
  --single-transaction --routines --triggers \
  uptimekuma > /backup/uk-mariadb-$(date +%Y%m%d-%H%M%S).sql

# Opcjonalnie: kompresja (dump SQL dobrze się kompresuje)
docker exec db mysqldump -u uptimekuma -p'silne_haslo' \
  --single-transaction --routines --triggers \
  uptimekuma | gzip > /backup/uk-mariadb-$(date +%Y%m%d-%H%M%S).sql.gz

Flaga --single-transaction zapewnia spójność danych bez blokowania tabel — dump odbywa się w ramach jednej transakcji InnoDB.

Kompletny backup MariaDB + pliki

Przy konfiguracji z MariaDB musisz backupować zarówno bazę danych, jak i katalog data/ Uptime Kuma (zawiera pliki upload, screenshots, ewentualne certyfikaty):

#!/bin/bash
# uk-mariadb-backup.sh — backup Uptime Kuma z MariaDB

BACKUP_DIR="/backup/uptime-kuma"
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_PATH="$BACKUP_DIR/uk-backup-$DATE"

mkdir -p "$BACKUP_PATH"

# 1. Dump bazy MariaDB
docker exec db mysqldump -u uptimekuma -p'silne_haslo' \
  --single-transaction --routines --triggers \
  uptimekuma > "$BACKUP_PATH/database.sql"

# 2. Kopiuj pliki Uptime Kuma (upload, screenshots)
cp -r /opt/uptime-kuma/data/upload "$BACKUP_PATH/" 2>/dev/null
cp -r /opt/uptime-kuma/data/screenshots "$BACKUP_PATH/" 2>/dev/null

# 3. Pakuj archiwum
tar -czf "$BACKUP_DIR/uk-backup-$DATE.tar.gz" -C "$BACKUP_DIR" "uk-backup-$DATE"
rm -rf "$BACKUP_PATH"

# 4. Retencja
find "$BACKUP_DIR" -name "uk-backup-*.tar.gz" -mtime +30 -delete

echo "[OK] MariaDB backup: $BACKUP_DIR/uk-backup-$DATE.tar.gz"

Alternatywa: mariadb-backup (fizyczny backup)

Dla bardzo dużych baz danych (setki tysięcy heartbeatów) fizyczny backup narzędziem mariadb-backup (dawniej Percona XtraBackup) jest szybszy niż logiczny dump:

# Fizyczny backup (szybszy dla dużych baz)
docker exec db mariadb-backup --backup \
  --target-dir=/backup/physical \
  --user=root --password='root_haslo'

# Przygotowanie backupu (konieczne przed przywróceniem)
docker exec db mariadb-backup --prepare --target-dir=/backup/physical

Przywracanie danych — krok po kroku

Backup bez przetestowanej procedury przywracania to tylko iluzja bezpieczeństwa. Poniżej znajdziesz szczegółowe instrukcje przywracania danych Uptime Kuma dla każdego scenariusza.

Przywracanie z kopii plików (SQLite)

# Docker
docker stop uptime-kuma

# Bare metal
pm2 stop uptime-kuma
# lub: systemctl stop uptime-kuma

# Przenieś aktualne dane (nie usuwaj!)
mv /opt/uptime-kuma/data /opt/uptime-kuma/data-old-$(date +%Y%m%d)

# Z archiwum tar.gz
mkdir -p /opt/uptime-kuma/data
tar -xzf /backup/uptime-kuma/uk-backup-20260324-030000.tar.gz \
  -C /opt/uptime-kuma/data

# Lub z kopii katalogu
cp -r /backup/uptime-kuma-20260324-030000/* /opt/uptime-kuma/data/

chown -R 1000:1000 /opt/uptime-kuma/data

# Uruchom
docker start uptime-kuma

# Sprawdź logi
docker logs -f uptime-kuma --tail 50

# Zweryfikuj w przeglądarce
# https://twoja-instancja.uptimekuma.eu

Przywracanie z dumpa SQL (SQLite)

Jeśli backup to plik .sql (utworzony przez sqlite3 .dump), przywracanie wygląda nieco inaczej:

# Zatrzymaj Uptime Kuma
docker stop uptime-kuma

# Utwórz nową bazę z dumpa SQL
sqlite3 /opt/uptime-kuma/data/kuma.db < /backup/kuma-20260324.sql

# Ustaw uprawnienia
chown 1000:1000 /opt/uptime-kuma/data/kuma.db

# Uruchom ponownie
docker start uptime-kuma

Przywracanie z dumpa MariaDB

# Zatrzymaj Uptime Kuma (ale zostaw MariaDB)
docker stop uptime-kuma

# Przywróć bazę danych
docker exec -i db mysql -u uptimekuma -p'silne_haslo' uptimekuma < /backup/uk-mariadb-20260324.sql

# Uruchom ponownie
docker start uptime-kuma

Przywracanie z JSON (import w GUI)

Jeśli masz plik JSON wyeksportowany z GUI (Settings → Backup → Export):

1. Zainstaluj nową, czystą instancję Uptime Kuma
2. Utwórz konto administratora
3. Przejdź do Settings → Backup → Import
4. Wybierz plik JSON i kliknij Import
5. Wybierz opcję: Skip existing (pomiń istniejące), Overwrite (nadpisz) lub Keep both (zachowaj oba)

Pamiętaj: import JSON przywraca konfigurację monitorów i powiadomień, ale nie przywraca historii heartbeatów.

Migracja Uptime Kuma między serwerami

Migracja Uptime Kuma na nowy serwer to w gruncie rzeczy backup + przywracanie z dodatkowym krokiem przeniesienia danych. Oto sprawdzona procedura krok po kroku.

Migracja instalacji Docker

# Zatrzymaj kontener
docker stop uptime-kuma

# Spakuj cały wolumen danych
tar -czf /tmp/uk-migration.tar.gz -C /opt/uptime-kuma/data .

# Opcjonalnie: skopiuj docker-compose.yml
cp /opt/uptime-kuma/docker-compose.yml /tmp/docker-compose.yml

# Przez SCP
scp /tmp/uk-migration.tar.gz user@nowy-serwer:/tmp/
scp /tmp/docker-compose.yml user@nowy-serwer:/opt/uptime-kuma/

# Lub przez rsync (lepsze dla dużych plików)
rsync -avz /tmp/uk-migration.tar.gz user@nowy-serwer:/tmp/

# Utwórz katalog danych
mkdir -p /opt/uptime-kuma/data

# Rozpakuj backup
tar -xzf /tmp/uk-migration.tar.gz -C /opt/uptime-kuma/data

# Ustaw uprawnienia (rootless Docker v2.x)
chown -R 1000:1000 /opt/uptime-kuma/data

# Uruchom kontener
cd /opt/uptime-kuma
docker compose up -d

# Sprawdź logi
docker compose logs -f

Migracja z SQLite na MariaDB

Jeśli przy okazji migracji chcesz przejść z SQLite na MariaDB (zalecane dla 500+ monitorów), możesz użyć narzędzia sqlite3-to-mysql:

# Instalacja narzędzia
pip install sqlite3-to-mysql

# Konwersja bazy
sqlite3mysql -f /opt/uptime-kuma/data/kuma.db \
  -d uptimekuma -u uptimekuma -p silne_haslo \
  -h localhost --mysql-integer-type

Migracja między wersjami Uptime Kuma

Przy migracji między wersjami (np. 1.x → 2.x) warto pamiętać o kilku rzeczach:

• Wersja 1.x → 2.x — migracja bazy odbywa się automatycznie przy pierwszym uruchomieniu nowej wersji. Uptime Kuma wykryje starą strukturę bazy i wykona migrację. Koniecznie zrób backup przed aktualizacją.
• Downgrade (2.x → 1.x) — nie jest oficjalnie wspierany. Migracja bazy jest jednokierunkowa. Jedyna opcja to przywrócenie pełnego backupu ze starszej wersji.
• Ta sama wersja — bezproblemowa migracja, wystarczy przenieść dane.

Weryfikacja i testowanie backupów

Backup, którego nie testujesz, jest schrodningerowskim backupem — nie wiesz, czy działa, dopóki nie spróbujesz go przywrócić. A wtedy może być już za późno. Regularna weryfikacja backupów powinna być stałym elementem Twojej procedury.

Automatyczna weryfikacja integralności

Dodaj do skryptu backupu kroki weryfikacyjne:

# Po utworzeniu backupu — weryfikacja archiwum
tar -tzf "$BACKUP_DIR/uk-backup-$DATE.tar.gz" > /dev/null 2>&1
if [ $? -eq 0 ]; then
    echo "[OK] Archiwum jest poprawne"
else
    echo "[BŁĄD] Archiwum jest uszkodzone!"
    # Wyślij alert
    exit 1
fi

# Weryfikacja bazy SQLite (sprawdź integralność)
# Rozpakuj tymczasowo
TMP_DIR=$(mktemp -d)
tar -xzf "$BACKUP_DIR/uk-backup-$DATE.tar.gz" -C "$TMP_DIR"
sqlite3 "$TMP_DIR/kuma.db" "PRAGMA integrity_check;" | head -1
# Powinno zwrócić: "ok"
rm -rf "$TMP_DIR"

Test przywracania na środowisku testowym

Najlepszym testem backupu jest faktyczne przywrócenie — na osobnym kontenerze Docker, aby nie wpływać na produkcję:

# Uruchom testowy kontener z backupem
TMP_DIR=$(mktemp -d)
tar -xzf /backup/uptime-kuma/uk-backup-latest.tar.gz -C "$TMP_DIR"

docker run --rm -d \
  --name uk-backup-test \
  -p 3002:3001 \
  -v "$TMP_DIR":/app/data \
  louislam/uptime-kuma:2

# Poczekaj na uruchomienie
sleep 10

# Sprawdź, czy aplikacja odpowiada
curl -s -o /dev/null -w "%{http_code}" http://localhost:3002
# Powinno zwrócić: 200

# Sprawdź liczbę monitorów w bazie
docker exec uk-backup-test sqlite3 /app/data/kuma.db \
  "SELECT COUNT(*) FROM monitor;"

# Zatrzymaj i usuń testowy kontener
docker stop uk-backup-test
rm -rf "$TMP_DIR"

Checklisty weryfikacji

Po przywróceniu backupu (testowym lub produkcyjnym) sprawdź:

• Czy możesz się zalogować (konto admina działa)?
• Czy wszystkie monitory są widoczne i mają poprawną konfigurację?
• Czy monitory rozpoczęły sprawdzanie (heartbeaty w dashboardzie)?
• Czy historia uptime jest widoczna (wykresy, procenty)?
• Czy powiadomienia są skonfigurowane (Telegram, Discord, email)?
• Czy strony statusu są dostępne i wyświetlają poprawne dane?
• Czy przesłane pliki (logo, favicony) są widoczne?
• Czy tagi, grupy i maintenance windows są zachowane?

Polityka retencji i przechowywanie kopii

Ile backupów przechowywać i jak długo? To zależy od krytyczności Twojej instalacji i dostępnego miejsca na dysku. Oto rekomendowane polityki retencji.

Rekomendowane schematy retencji

Schemat rotacji GFS (Grandfather-Father-Son)

Dla krytycznych instalacji warto zastosować schemat GFS, który łączy krótkoterminową granularność z długoterminowym przechowywaniem:

• Son (dzienne) — ostatnie 7 dni, backup codziennie
• Father (tygodniowe) — ostatnie 4 tygodnie, backup w niedzielę
• Grandfather (miesięczne) — ostatnie 12 miesięcy, backup 1-go dnia miesiąca

#!/bin/bash
# Implementacja rotacji GFS
BACKUP_DIR="/backup/uptime-kuma"
DATE=$(date +%Y%m%d)
DOW=$(date +%u)  # 1=pon, 7=niedz
DOM=$(date +%d)  # Dzień miesiąca

# Wykonaj backup
/usr/local/bin/uptime-kuma-backup.sh

# Kopiuj do odpowiednich katalogów retencji
LATEST="$BACKUP_DIR/uk-backup-$DATE.tar.gz"

# Dzienne — zawsze
cp "$LATEST" "$BACKUP_DIR/daily/"

# Tygodniowe — w niedzielę
if [ "$DOW" -eq 7 ]; then
    cp "$LATEST" "$BACKUP_DIR/weekly/"
fi

# Miesięczne — pierwszego dnia miesiąca
if [ "$DOM" -eq "01" ]; then
    cp "$LATEST" "$BACKUP_DIR/monthly/"
fi

# Retencja
find "$BACKUP_DIR/daily/" -mtime +7 -delete
find "$BACKUP_DIR/weekly/" -mtime +28 -delete
find "$BACKUP_DIR/monthly/" -mtime +365 -delete

Szacowanie rozmiaru backupów

Rozmiar backupu Uptime Kuma zależy głównie od liczby monitorów i retencji danych (heartbeatów):

• Czysta instalacja — ~500 KB
• 10 monitorów, 30 dni retencji — ~5-15 MB
• 50 monitorów, 180 dni retencji — ~50-150 MB
• 200 monitorów, 365 dni retencji — ~200-500 MB
• Po kompresji gzip — rozmiar zmniejsza się o 60-80% (dane SQLite dobrze się kompresują)

Best practices — reguła 3-2-1, szyfrowanie, off-site

Profesjonalna strategia backupu to więcej niż skrypt i cron. Oto sprawdzone praktyki, które ochronią Twoje dane monitoringu przed każdym scenariuszem awarii.

Reguła 3-2-1

Złota zasada backupu, sprawdzona od dekad i nadal aktualna:

• 3 kopie danych — oryginał + 2 kopie zapasowe
• 2 różne nośniki — np. dysk lokalny + storage w chmurze
• 1 kopia off-site — poza fizyczną lokalizacją serwera (na wypadek pożaru, kradzieży, awarii DC)

Dla Uptime Kuma w praktyce może to wyglądać tak:

1. Kopia 1 — oryginalne dane na serwerze (/opt/uptime-kuma/data/)
2. Kopia 2 — backup na osobnym dysku na tym samym serwerze (/backup/)
3. Kopia 3 — backup off-site: S3, Backblaze B2, Google Drive, Nextcloud lub inny serwer

Wysyłanie backupów off-site

Kilka popularnych metod przesyłania backupów na zewnętrzny storage:

# === rclone — uniwersalne narzędzie do cloud storage ===
# (obsługuje S3, Backblaze B2, Google Drive, OneDrive, SFTP i 50+ providerów)
rclone copy /backup/uptime-kuma/uk-backup-latest.tar.gz remote:uptime-kuma-backups/

# === AWS S3 (lub kompatybilne: MinIO, Wasabi, Backblaze B2) ===
aws s3 cp /backup/uptime-kuma/uk-backup-latest.tar.gz \
  s3://moj-bucket/uptime-kuma-backups/

# === rsync na zdalny serwer ===
rsync -avz /backup/uptime-kuma/ user@backup-server:/backup/uptime-kuma/

# === SCP na zdalny serwer ===
scp /backup/uptime-kuma/uk-backup-latest.tar.gz \
  user@backup-server:/backup/uptime-kuma/

Szyfrowanie backupów

Backup Uptime Kuma zawiera wrażliwe dane — tokeny API, webhooki, hasła SMTP, poświadczenia baz danych i tokeny powiadomień (Telegram, Discord, Slack). Szyfrowanie backupów jest obowiązkowe, zwłaszcza przy przechowywaniu off-site.

# Szyfrowanie za pomocą GPG (symetryczne, hasłem)
tar -czf - -C /opt/uptime-kuma/data . | \
  gpg --symmetric --cipher-algo AES256 \
  --passphrase-file /root/.backup-passphrase \
  -o /backup/uk-backup-$(date +%Y%m%d).tar.gz.gpg

# Deszyfrowanie
gpg --decrypt --passphrase-file /root/.backup-passphrase \
  /backup/uk-backup-20260324.tar.gz.gpg | tar -xzf - -C /opt/uptime-kuma/data

# Alternatywnie: openssl
tar -czf - -C /opt/uptime-kuma/data . | \
  openssl enc -aes-256-cbc -salt -pbkdf2 \
  -pass file:/root/.backup-passphrase \
  -out /backup/uk-backup-$(date +%Y%m%d).tar.gz.enc

Backup w środowiskach z wieloma instancjami

Jeśli zarządzasz wieloma instancjami Uptime Kuma (np. dla różnych klientów lub środowisk), warto scentralizować backup:

#!/bin/bash
# Multi-instance backup
INSTANCES=(
    "produkcja:/opt/uk-prod/data"
    "staging:/opt/uk-staging/data"
    "dev:/opt/uk-dev/data"
)

for INSTANCE in "${INSTANCES[@]}"; do
    NAME="${INSTANCE%%:*}"
    DATA_DIR="${INSTANCE##*:}"

    BACKUP_FILE="/backup/uk-$NAME-$(date +%Y%m%d).tar.gz"

    sqlite3 "$DATA_DIR/kuma.db" ".backup '/tmp/kuma-$NAME.db'"
    tar -czf "$BACKUP_FILE" -C "$DATA_DIR" upload screenshots \
      -C /tmp "kuma-$NAME.db"
    rm /tmp/kuma-$NAME.db

    echo "[OK] $NAME → $BACKUP_FILE"
done

Dodatkowe best practices

• Monitoruj swoje backupy — użyj Push monitora w Uptime Kuma, aby wykrywać nieudane backupy
• Dokumentuj procedurę przywracania — w stresie łatwo o błędy, dlatego miej spisaną checklist recovery
• Testuj przywracanie regularnie — raz w miesiącu uruchom pełny test restore na środowisku testowym
• Nie przechowuj backupów na tym samym dysku — awaria dysku zabierze i oryginał, i backup
• Versionuj skrypty backupu — trzymaj je w Git, aby śledzić zmiany i mieć historię
• Alertuj o problemach z dyskiem — monitoruj wolne miejsce na partycji backupowej
• Backup przed aktualizacją — zawsze twórz ręczny backup przed docker pull i restartam kontenera
• Wykluczaj screenshots z backupów — jeśli używasz monitora Real Browser, katalog screenshots/ może szybko urosnąć, a zrzuty ekranu nie są krytyczne

Podsumowanie

Backup Uptime Kuma to nie opcja — to konieczność. Twój system monitoringu to pierwsza linia obrony przed awariami, a jego utrata oznacza ślepotę na problemy w infrastrukturze. Dobrze skonfigurowany backup pozwala przywrócić pełną funkcjonalność monitoringu w minuty, nie w godziny czy dni.

Kluczowe wnioski z tego przewodnika:

• Baza SQLite (kuma.db) to serce Uptime Kuma — zawiera całą konfigurację i historię. Backupuj ją za pomocą sqlite3 .backup (bez przestoju) lub przez kopiowanie plików (z zatrzymaniem)
• Automatyzuj backup — skrypt bash + cron to minimum. Dodaj weryfikację integralności i powiadomienia o statusie
• Docker: bind mount lub named volume — obie metody mają sprawdzone procedury backupu i przywracania
• MariaDB (v2.x) — używaj mysqldump --single-transaction dla spójnych kopii bez przestoju
• Testuj przywracanie — uruchamiaj testowy kontener z backupem raz w miesiącu
• Stosuj regułę 3-2-1 — 3 kopie, 2 nośniki, 1 off-site. Szyfruj kopie przechowywane poza serwerem
• Monitoruj backup — Push monitor w Uptime Kuma poinformuje Cię, gdy backup się nie wykona

Jeśli wolisz skupić się na monitorowaniu usług, a nie na zarządzaniu infrastrukturą backupową — hosting zarządzany na SmartXHosting.pl zdejmie z Ciebie ten obowiązek. Codzienny backup, retencja, przechowywanie i wsparcie techniczne — wszystko w cenie usługi.

Najczęściej zadawane pytania