Dlaczego backup monitoringu jest krytyczny • Co przechowuje Uptime Kuma — anatomia danych • Backup ręczny — kopiowanie plików i dump SQLite • Automatyczny backup — skrypty i cron • Backup wolumenów Docker • Backup z MariaDB/MySQL (wersja 2.x) • Przywracanie danych — krok po kroku • Migracja Uptime Kuma między serwerami • Weryfikacja i testowanie backupów • Polityka retencji i przechowywanie kopii • Best practices — reguła 3-2-1, szyfrowanie, off-site • Podsumowanie • Najczęściej zadawane pytania
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:
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.
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)
└── *.pngTo serce Uptime Kuma — pojedynczy plik SQLite zawierający absolutnie wszystko:
| Dane | Opis | Znaczenie dla backupu |
|---|---|---|
| Monitory | Konfiguracja wszystkich monitorów (URL, typ, interwał, retries, headers, auth) | Krytyczne — odtworzenie ręczne bardzo czasochłonne |
| Heartbeaty | Historia sprawdzeń (status, czas odpowiedzi, timestampy) | Ważne — dane SLA, wykresy, historia downtime |
| Powiadomienia | Konfiguracja kanałów (Telegram tokeny, Slack webhooki, SMTP, itp.) | Krytyczne — zawiera dane uwierzytelniające |
| Strony statusu | Konfiguracja, grupy monitorów, custom CSS, domeny | Ważne — rekonfiguracja zajmuje czas |
| Użytkownicy | Konta, hasła (zahashowane), tokeny API | Krytyczne — utrata oznacza brak dostępu |
| Maintenance | Okna serwisowe (maintenance windows) | Średnie — łatwe do odtworzenia |
| Tagi i grupy | Organizacja monitorów (tagi kolorowe, grupy) | Średnie — ale ważne przy dużych instalacjach |
| Ustawienia | Globalne ustawienia (retencja danych, motyw, język, itp.) | Niskie — szybkie do odtworzenia |
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ę.
kuma.db nie istnieje — dane są przechowywane w zewnętrznej bazie danych, a backup wymaga użycia narzędzi takich jak mysqldump. Sekcja o backupie MariaDB znajduje się dalej w artykule.
Najprostszą metodą backupu jest ręczne skopiowanie danych. To dobry punkt wyjścia i warto zrozumieć ten proces, zanim przejdziesz do automatyzacji.
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-kumaDla 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-kumaKomenda 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).sqlPamię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"sqlite3 .backup korzysta z wbudowanego API backupu SQLite i jest bezpieczne do użycia na działającej bazie. W odróżnieniu od zwykłego cp, uwzględnia transakcje WAL i gwarantuje integralność danych. To preferowana metoda backupu bazy SQLite w produkcji.
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:
Funkcja importu (Settings → Backup → Import) pozwala wczytać taki plik JSON do nowej lub istniejącej instancji — przydatne do szybkiego odtworzenia konfiguracji monitorów.
Ręczny backup jest dobry na start, ale w produkcji musisz go zautomatyzować. Najprościej to zrobić za pomocą skryptu bash i crona.
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"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>&1Nie zapomnij nadać uprawnień do wykonywania:
chmod +x /usr/local/bin/uptime-kuma-backup.shWarto 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/nullWię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.
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-stoppedJeś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.
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 startJeś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.dbnode (UID 1000), nie root. Upewnij się, że katalog docelowy backupu w kontenerze ma odpowiednie uprawnienia. Polecenie sqlite3 jest dostępne wewnątrz oficjalnego obrazu 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"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.
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: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.gzFlaga --single-transaction zapewnia spójność danych bez blokowania tabel — dump odbywa się w ramach jednej transakcji InnoDB.
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"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/physicalBackup bez przetestowanej procedury przywracania to tylko iluzja bezpieczeństwa. Poniżej znajdziesz szczegółowe instrukcje przywracania danych Uptime Kuma dla każdego scenariusza.
1.
Przed przywracaniem danych zawsze zatrzymaj aplikację, aby uniknąć konfliktów zapisu.
# Docker
docker stop uptime-kuma
# Bare metal
pm2 stop uptime-kuma
# lub: systemctl stop uptime-kuma2.
Na wypadek gdyby backup okazał się uszkodzony, zachowaj aktualne dane:
# Przenieś aktualne dane (nie usuwaj!)
mv /opt/uptime-kuma/data /opt/uptime-kuma/data-old-$(date +%Y%m%d)3.
Rozpakuj archiwum backupu do katalogu danych:
# 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/4.
Od wersji 2.0 kontener Docker działa jako użytkownik node (UID 1000). Upewnij się, że pliki mają odpowiednie uprawnienia:
chown -R 1000:1000 /opt/uptime-kuma/data5.
Uruchom aplikację i sprawdź, czy wszystko działa poprawnie:
# Uruchom
docker start uptime-kuma
# Sprawdź logi
docker logs -f uptime-kuma --tail 50
# Zweryfikuj w przeglądarce
# https://twoja-instancja.uptimekuma.eu1.
# 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.yml2.
# 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/3.
# 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 -f4.
Po sprawdzeniu, że nowa instancja działa poprawnie (monitory aktywne, powiadomienia skonfigurowane, strony statusu dostępne), zaktualizuj DNS lub konfigurację reverse proxy, aby ruch kierował na nowy serwer. Starą instancję wyłącz dopiero po potwierdzeniu działania nowej.
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# 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-kumaJeśli masz plik JSON wyeksportowany z GUI (Settings → Backup → Export):
Pamiętaj: import JSON przywraca konfigurację monitorów i powiadomień, ale nie przywraca historii heartbeatów.
Migracja Uptime Kuma na nowy serwer to w gruncie rzeczy backup + przywracanie z dodatkowym krokiem przeniesienia danych. Oto sprawdzona procedura krok po kroku.
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-typeUPTIME_KUMA_DB_TYPE=mariadb) w docker-compose.yml.
Przy migracji między wersjami (np. 1.x → 2.x) warto pamiętać o kilku rzeczach:
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.
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"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"Po przywróceniu backupu (testowym lub produkcyjnym) sprawdź:
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.
| Scenariusz | Częstotliwość | Retencja | Szacowany rozmiar |
|---|---|---|---|
| Homelab / osobiste | Codziennie | 7 dni | ~50-200 MB (7 kopii) |
| Mała firma (10-50 monitorów) | Codziennie | 30 dni | ~200 MB - 1 GB |
| Średnia firma (50-200 monitorów) | Co 6 godzin | 30 dni (dzienne) + 12 mies. (tygodniowe) | ~1-5 GB |
| Enterprise (200+ monitorów) | Co godzinę | 7 dni (godzinowe) + 90 dni (dzienne) + 2 lata (miesięczne) | ~5-20 GB |
Dla krytycznych instalacji warto zastosować schemat GFS, który łączy krótkoterminową granularność z długoterminowym przechowywaniem:
#!/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 -deleteRozmiar backupu Uptime Kuma zależy głównie od liczby monitorów i retencji danych (heartbeatów):
Profesjonalna strategia backupu to więcej niż skrypt i cron. Oto sprawdzone praktyki, które ochronią Twoje dane monitoringu przed każdym scenariuszem awarii.
Złota zasada backupu, sprawdzona od dekad i nadal aktualna:
Dla Uptime Kuma w praktyce może to wyglądać tak:
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/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.encJeś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"
doneBackup 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:
sqlite3 .backup (bez przestoju) lub przez kopiowanie plików (z zatrzymaniem)mysqldump --single-transaction dla spójnych kopii bez przestojuJeś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.
Nie. Uptime Kuma oferuje jedynie ręczny eksport konfiguracji do pliku JSON z poziomu GUI (Settings → Backup). Ten eksport nie obejmuje historii heartbeatów ani przesłanych plików. Pełny automatyczny backup (bazy danych, plików, retencja) musisz skonfigurować samodzielnie za pomocą skryptów i crona. Na hostingu zarządzanym (np. SmartXHosting.pl) backup jest wykonywany automatycznie.
Zatrzymaj kontener na starym serwerze, spakuj katalog danych (tar -czf), przenieś archiwum na nowy serwer (SCP/rsync), rozpakuj do katalogu danych, ustaw uprawnienia (chown 1000:1000 dla Docker v2.x) i uruchom kontener. Cała operacja trwa kilka minut. Szczegółowa procedura krok po kroku jest opisana w sekcji o migracji w tym artykule.
Tak. Użyj polecenia sqlite3 kuma.db ".backup 'kopia.db'", które korzysta z wbudowanego API backupu SQLite i tworzy spójną kopię nawet na działającej bazie. Nie używaj zwykłego cp na działającej bazie — kopia może być uszkodzona z powodu niezapisanych transakcji WAL.
Rozmiar zależy od liczby monitorów i retencji danych. Typowa instalacja z 50 monitorami i 180-dniową retencją zajmuje ok. 50-150 MB (baza SQLite). Po kompresji gzip rozmiar maleje o 60-80%. Czysta instalacja to zaledwie ~500 KB. Katalog screenshots/ (monitor Real Browser) może znacząco zwiększyć rozmiar — warto go wykluczyć z regularnych backupów.
Dla homelaba i małych instalacji wystarczy backup raz dziennie. Dla firm i krytycznych wdrożeń rekomendujemy backup co 6 godzin z 30-dniową retencją. W przypadku dużych, dynamicznych instalacji (częste zmiany konfiguracji, setki monitorów) — backup co godzinę ze schematem retencji GFS (dzienne/tygodniowe/miesięczne).
Nie jako jedyna metoda. Eksport JSON zawiera konfigurację monitorów i powiadomień, ale nie zawiera historii heartbeatów (danych uptime/downtime), danych użytkowników ani przesłanych plików. Jest przydatny jako szybki eksport konfiguracji i uzupełnienie pełnego backupu bazy danych, ale nie powinien być jedyną strategią backupu.
Użyj mysqldump z flagą --single-transaction dla spójnego dumpa bez blokowania tabel. Dodatkowo skopiuj katalog data/ z Uptime Kuma (zawiera pliki upload i screenshots). Pełna procedura jest opisana w dedykowanej sekcji tego artykułu. Pamiętaj o osobnym backupie zarówno bazy MariaDB, jak i plików Uptime Kuma.