Backups
Backup-Monitoring — wissen, wenn ein Backup nicht lief
Überwachen Sie jedes Backup mit einem einzeiligen Ping — und werden Sie alarmiert, wenn ein Datenbank-Dump, restic-/borg-Lauf oder S3-Sync seinen Zeitplan verpasst, fehlschlägt oder hängt.
Das Problem
Backups sind der klassische stille Ausfall. Der Cronjob läuft, der Dump scheitert — Platte voll, abgelaufene Zugangsdaten, ein Netzwerk-Aussetzer — und nichts sagt es Ihnen. Sie merken es Wochen später, mitten in einem Vorfall, wenn das dringend benötigte Backup sich als leer oder ganz fehlend erweist.
So löst SteadyCron das
- 1 Legen Sie einen Heartbeat-Check passend zu Ihrem Backup-Zeitplan an (z. B. täglich um 02:00) und setzen Sie eine Kulanzzeit, die normale Schwankungen abfängt.
- 2 Pingen Sie SteadyCron am Ende Ihres Backup-Skripts bei Erfolg — und explizit bei Fehler, falls der Dump-Befehl scheitert.
- 3 Kommt der Erfolgs-Ping nicht innerhalb der Kulanzzeit an, alarmiert Sie SteadyCron per E-Mail, Slack, Discord, Telegram oder Webhook.
#!/usr/bin/env bash
TOKEN=<ihr-ping-token>
if pg_dump "$DATABASE_URL" | zstd | age -r "$KEY" > /backups/db.sql.zst.age; then
curl -fsS https://ping.steadycron.com/$TOKEN
else
curl -fsS https://ping.steadycron.com/$TOKEN/fail
fi
Jobs
| weekly-digest-email | HTTP | 0 9 * * 1 | in 2 days | 3 days ago | ||
| nightly-db-backup | Heartbeat | 0 2 * * * | in 19 h | 5 h ago | ||
| stripe-reconciliation | HTTP | 0 */4 * * * | in 38 min | 3 h ago | ||
| cache-warmup | HTTP | */15 * * * * | in 11 min | now | ||
| search-index-sync | Heartbeat | */30 * * * * | in 6 min | 24 min ago |
| seed-test-data | HTTP | 0 4 * * * | in 14 h | 10 h ago | ||
| preview-env-cleanup | Heartbeat | 0 */6 * * * | in 2 h | 4 h ago | ||
| trial-expiry-sweep | HTTP | 0 6 * * * | — | yesterday |
Status, Zeitplan und letzter Lauf jedes Jobs — auf einen Blick.
Warum ein Heartbeat und nicht nur ein Exit-Code
Der Exit-Code Ihres Skripts zählt nur, wenn etwas ihn beobachtet — und auf einer einsamen VM tut das nichts. Ein Heartbeat verlagert die Frage „Lief es?“ weg von der Maschine, die selbst ausgefallen sein könnte. Wenn der Server neu startet, die Platte volläuft oder Cron falsch konfiguriert ist, kommt der Ping schlicht nicht an, und SteadyCron sagt es Ihnen.
Funktioniert mit jedem Backup-Tool
Backup-Monitoring kümmert es nicht, was das Backup erzeugt — nur, dass es fertig wurde. Derselbe einzeilige Ping funktioniert für:
- Datenbank-Dumps —
pg_dump,mysqldump,mongodump, SQL-Server-Wartungspläne - Datei- und System-Backups —
restic,borg,duplicity,rsync,tar-Rotationen - Cloud-Syncs —
rcloneoderaws s3 syncin den Objektspeicher - Windows — Aufgabenplanungs-Jobs pingen mit einer einzigen
curl.exe- oder PowerShell-Invoke-RestMethod-Zeile
Alles, was einen HTTP-Request senden kann, lässt sich überwachen. Kein Agent, kein SDK.
Erkennen Sie auch hängende Backups
Senden Sie am Anfang des Skripts einen /start-Ping. Wenn ein Backup beginnt, aber
nie seinen /success- oder /fail-Ping sendet — weil es an einem Lock hing oder
der Speicher ausging — markiert SteadyCron den Lauf als hängend, nicht nur als
verspätet.
Erkennen Sie Backups, die still verkümmern
Ein Backup, das in zwei Sekunden „erfolgreich“ ist, ist meist ein Backup von nichts. Die Anomalie-Trigger von SteadyCron vergleichen jeden Job mit seiner eigenen Baseline: Ein Lauf, der deutlich schneller oder langsamer als sein Median endet, oder eine plötzlich schrumpfende Antwortgröße kann einen Alarm auslösen — auch wenn der Exit-Code behauptet, alles sei in Ordnung.
Ihre Backup-Metadaten bleiben in der EU
Ping-Zeitstempel, Job-Namen und Alarm-Historie liegen auf Hetzner-Infrastruktur in Deutschland — keine US-Subdienstleister im Ausführungspfad, ein DSGVO-DPA ist verfügbar. Die Backup-Daten selbst erreichen SteadyCron nie; nur der Ping tut es.
Verwandte Dokumentation
Erfahren Sie es nicht erst im Ernstfall
Starten Sie mit dem kostenlosen Tarif — keine Kreditkarte erforderlich.
Kostenlos starten