🚀 Quickstart

Installation & Aktivierung

Lade die ZIP-Datei aus deinem Backsta-Konto herunter (/konto/).
WordPress-Admin → Plugins → Installieren → Plugin hochladen → ZIP wählen → Jetzt installieren → Aktivieren.
Nach der Aktivierung erscheint links in der Sidebar der Menüpunkt Backsta mit Cloud-Upload-Icon.

Mindestanforderungen: WordPress 6.0+, PHP 8.0+, ZipArchive (i.d.R. überall vorhanden), für Verschlüsselung OpenSSL mit AES-256-GCM (auf 99 % aller Hostings dabei).

Lizenz-Aktivierung

Tab Lizenz öffnen.
Lizenzschlüssel aus der Bestätigungs-E-Mail einfügen.
Lizenz aktivieren klicken — Backsta validiert online gegen backsta.io und merkt sich die Aktivierung pro Site.

Site-Limit: Single-Lizenz = 1 Site, Agency = 25 Sites, Founders Stack = unlimited. Beim Umzug einer Site (alte abschalten, neue aktivieren) gibt's im Konto die Site freigeben-Funktion.

Offline-Hosting: Falls dein Server kein backsta.io erreichen kann (paranoide Firewalls), steht im Lizenz-Tab eine manuelle Aktivierung über Token zur Verfügung.

Erstes Backup erstellen

Tab Backups → großer Start-Button rechts oben.
Backup läuft chunked im Hintergrund — du kannst die Page schließen, der Job läuft weiter.
Live-Progress-Bar zeigt DB-Dump und File-Archive parallel.
Fertig: das Backup taucht in der Liste „Verfügbare Backups" auf, mit Größe + Zeitstempel.

Tipp: Beim allerersten Backup empfehlen wir, im Tab Umfang nichts zu ändern (Defaults: DB + Uploads + Themes + Plugins). Sobald das durchgelaufen ist, weißt du wie groß ein Voll-Backup auf deiner Site ist und kannst von dort aus optimieren.

Restore testen (Dry-Run)

Bevor du dich auf ein Backup verlässt, einmal verifizieren dass es funktioniert. Backsta kann das ohne deine Site anzufassen:

Tab Wiederherstellen → Backup auswählen → Dry-Run.
Backsta öffnet die ZIP, validiert die SQL-Datei syntaktisch, prüft die File-Liste — meldet zurück ob ein echter Restore klappen würde.
Der Dry-Run schreibt nichts in die DB und nichts auf Disk außerhalb von wp-content/backups/backsta/dryrun/.

Automatisierung: Statt manuell zu testen → Tab Sicherheit → Restore Self-Test aktivieren. Läuft wöchentlich automatisch und schickt eine Mail bei Problemen.

📦 Backup-Konfiguration

Umfang (Tab „Umfang")

Hier definierst du was in jedes Backup hineingeht. Vier Toggles + zwei Ausschluss-Felder:

Datenbank — alle WP-Tabellen mit dem aktuellen Prefix. Standardmäßig an.
Uploads — Inhalt von wp-content/uploads/ (Mediathek). Bei Sites mit großer Mediathek der größte Posten.
Themes — alle Themes (auch inaktive). Klein.
Plugins — alle Plugins (auch deaktivierte). Mittelgroß.
Root-Files (optional, default aus) — alles unterhalb von WP-Root: wp-config.php, .htaccess, eigene Skripte. Aktivieren wenn du außerhalb von wp-content Custom-Code hast.

Ausschlussregeln: Im Feld Backup-Ausschluss eine Pfad-Regel pro Zeile — Backsta kennt schon die offensichtlichen Verdächtigen (wp-content/cache, wp-content/upgrade, node_modules). Eigene Regeln dazupacken wenn du z.B. einen wp-content/uploads/temp/-Ordner hast.

Tabellen ausschließen: Im Feld Tabellen-Ausschluss SQL-Tabellen-Namen (mit Prefix). Klassiker: wp_actionscheduler_logs und wp_actionscheduler_actions bei WooCommerce-Sites — die können mehrere GB groß werden ohne wirklich gebraucht zu sein.

Max-Größe: Default 2048 MB (= 2 GB). Über diesem Wert bricht Backsta ab statt einen halben Archive-Frankenstein zu produzieren. Bei wirklich großen Sites in 4096–8192 ändern, oder besser: Inkrementell aktivieren.

Inkrementell- & Differential-Mode

Beide reduzieren Backup-Größe drastisch nach dem ersten Voll-Backup, mit unterschiedlicher Strategie:

Inkrementell (Tab Umfang) — nur Files, die sich seit dem letzten beliebigen Backup geändert haben. Klein, schnell, aber Restore braucht eine ganze Kette von ZIPs.
Differential (Tab Umfang, eigener Toggle) — nur Files seit dem letzten Voll-Backup. Größer als Inkrementell aber Restore = Voll-Backup + 1 Diff-ZIP, fertig.

Empfehlung: Differential für die meisten Sites. Inkrementell nur wenn Disk knapp ist. Voll-Backup mindestens 1× pro Woche, sonst werden Diff-Ketten unhandlich.

Schwelle: Wenn ein Differential größer als die hier eingetragene MB-Schwelle wird, springt Backsta automatisch auf ein Voll-Backup zurück — sonst wird der Diff irgendwann größer als das Original.

Verschlüsselung (Tab „Sicherheit")

Backups verschlüsseln aktivieren — Backsta nutzt seit v1.7.7 chunked AES-256-GCM (Container-Format RES2) mit PBKDF2-SHA256 und 600 000 Iterationen (NIST/OWASP-2024-konform). Per-Chunk-Authentication-Tag mit Index als AAD verhindert Reorder- und Truncation-Angriffe.
Passphrase setzen — mindestens 16 Zeichen, aus mehreren Wörtern + Zahlen + Sonderzeichen. Diese Passphrase wird nie an Backsta-Server geschickt.
Verschlüsselte Backups bekommen die Endung .zip.rsv.

⚠️ Sehr wichtig: Bewahre die Passphrase OFFLINE auf — Passwortmanager, Notizbuch im Safe, USB-Stick im Bankschließfach. Ohne sie ist KEIN Restore möglich, auch nicht von uns. Wir haben sie nicht und können sie nicht reconstruieren.

Streaming statt Memory: Vor v1.7.7 lief Encryption single-shot (ganze Datei in den Speicher). Seit v1.7.7 wird in 4-MiB-Chunks verschlüsselt — funktioniert auch mit 25-GB-Backups auf einem 128-MB-PHP-memory_limit-Hoster. Alte Backups im RES1-Format bleiben weiterhin entschlüsselbar (Backwards-Compatibility-Pfad).

Performance: Verschlüsselung kostet ~10–15 % CPU-Zeit beim Backup. Auf shared Hosting kann das ein Voll-Backup 2× so lange laufen lassen — bei knappen Time-Limits dann besser inkrementell + nur ein Voll-Backup pro Woche verschlüsseln.

Multisite-per-Subsite-Auswahl

Auf einer WP-Multisite (Network) gibt es im Network-Admin einen eigenen Tab Sites. Dort:

Pro Subsite einzeln aktivieren ob sie ins Backup geht.
Globale Defaults (Schedule, Storage, Encryption) für alle Subsites.
Per-Subsite-Override: einzelne Sites mit eigenem Schedule oder eigenem S3-Bucket.

Was Backsta auf Multisite macht: einen Voll-Dump der Network-DB (alle wp_+wp_2_+wp_3_… Tabellen), plus alle wp-content/uploads/sites/X/-Ordner für die ausgewählten Sites. Restore ist dann auch network-aware.

⏰ Zeitplan & Retention

Frequenz wählen

Tab Zeitplan. Verfügbare Frequenzen:

15-min, 30-min, stündlich — für High-Change-Sites (WooCommerce mit häufigen Bestellungen, Foren, Membership-Sites).
Custom-Minuten — eigene Frequenz zwischen 5 und 10 080 Minuten.
täglich — Sweet-Spot für die meisten Sites. Standard-Empfehlung.
wöchentlich — für rein statische Sites die selten editiert werden.
monatlich — als Ergänzung zum Voll-Backup-Rhythmus, kombiniert mit Pre-Update-Backups (s.u.).

WP-Cron auf stillen Sites: WordPress führt geplante Tasks nur aus wenn jemand die Site besucht. Auf Sites mit wenig Traffic einen externen System-Cron einrichten, der wp-cron.php alle paar Minuten anpingt — sonst laufen Backups verzögert oder gar nicht.

Blackout-Windows: Im selben Tab kannst du Zeitfenster definieren in denen NIE ein Backup läuft (z.B. „Mo-Fr 09:00–17:00 — keine Storage-Last während Office-Hours"). Eine Regel pro Zeile.

Retention-Regeln

Steuerung wie viele alte Backups behalten werden:

Anzahl Backups behalten (Default 7) — sobald ein neues Backup angelegt wird und das Limit erreicht ist, löscht Backsta automatisch das älteste.
Zusätzlich Monats-Backups behalten (Default 3) — das jeweils erste Backup eines Monats wird ZUSÄTZLICH zur normalen Retention behalten. Mit 3 hast du die letzten 3 Monatsstände, auch wenn die normale Retention sie längst gelöscht hätte.

Beispiel: Tägliche Backups, Retention 7 + Monats-Retention 3 → du hast immer die letzten 7 Tage plus die letzten 3 Monatsanfänge. Disk-Bedarf: ~10 Backup-ZIPs.

Pre-Update Auto-Backup

Tab Zeitplan ganz unten. Drei unabhängige Trigger:

Vor Plugin-Updates — bei jedem Plugin-Update ein vollständiges Backup, bevor WordPress die Files austauscht.
Vor Theme-Updates — analog für Themes.
Vor WP-Core-Updates — bei Core-Updates (auch Auto-Updates).
Vor manuellem ZIP-Upload — wenn du selbst eine Plugin/Theme-ZIP über „Plugin hochladen → bestehendes ersetzen" hochlädst. Der riskanteste Fall, daher Default an.

Backsta zeigt während des Update-Vorgangs eine eigene Live-Progress-Karte direkt auf der WP-Update-Seite — du siehst „🛡️ Backsta sichert …" statt einer eingefrorenen Page.

Nach erfolgreichem Pre-Update-Backup taucht in der Sidebar (Plugins-Page, Themes-Page) ein Hinweis auf: Rollback verfügbar. Ein-Klick-Revert zurück zum Vor-Update-Stand, falls das Update Probleme bringt.

Versions-Archiv konfigurieren

Versions-Archiv ist die chirurgische Variante zum Pre-Update-Voll-Backup: vor jedem Plugin/Theme-Update wird der ALTE Folder als kleine ZIP archiviert — nur dieses eine Plugin, nichts anderes.

Tab Versions-Archiv:

Aktiv (Default an) — beide Trigger arbeiten unabhängig vom Pre-Update-Voll-Backup. Use-Cases sind unterschiedlich.
Versionen pro Plugin/Theme behalten (Default 5) — älter als N Versionen wird automatisch gelöscht.

Use-Case: Plugin-Update kaputt? Im Versions-Archiv-Tab das gewünschte Plugin → frühere Version → Zurücksetzen klicken. Datenbank und alle anderen Plugins bleiben unangetastet — viel weniger Risiko als ein Voll-Restore.

☁️ Cloud-Storage

Backups werden standardmäßig in wp-content/backups/backsta/ abgelegt. Für 3-2-1-Backup-Strategie (3 Kopien, 2 Medien, 1 off-site) müssen sie zusätzlich nach extern. Tab Speicher:

Amazon S3 / S3-kompatibel

Funktioniert mit AWS S3, Hetzner Object Storage, MinIO, Backblaze B2, Wasabi, Cloudflare R2 — kurz: alles mit S3-API.

Bucket anlegen, IAM-User mit s3:PutObject + s3:ListBucket + s3:DeleteObject für diesen Bucket.
Tab Speicher → S3 aktivieren:
- Endpoint: leer = AWS, sonst s3.eu-central-1.hetznerobjects.com / etc.
- Region: eu-central-1 für Frankfurt.
- Bucket, Access Key, Secret Key.
- Prefix (z.B. backups/example.com/) — sortiert mehrere Sites in einen Bucket.
- Path-Style aktivieren wenn dein Provider keine virtuelle-Hosted-Style-URLs kann (MinIO & Co.).
Verbindung testen-Button drücken — uploaded eine 1-Byte-Test-Datei und löscht sie wieder.

Tipp: Bucket-Lifecycle-Policy auf S3-Provider-Seite aktivieren um alte Backups auf günstigeren Cold-Storage zu schieben (S3 Glacier, B2 archive).

FTP / SFTP

Tab Speicher → FTP aktivieren.
Host, Port (21 für FTP, 22 für SFTP), User, Passwort, Zielpfad (/backups/).
SFTP-Toggle setzen falls dein Server SSH-File-Transfer statt klassisches FTP nutzt.
Passive-Mode meist aktiv lassen — nur abstellen wenn der Server explizit Active-Mode verlangt.

Sicherheit: Klassisches FTP überträgt Passwort im Klartext. Auf Hostings mit SFTP-Support ALWAYS SFTP nehmen.

Google Drive

Backsta v1.1 hat einen One-Click-Cloud-Connect — du brauchst KEIN eigenes Google-Cloud-Project mehr.

Tab Speicher → Google-Drive-Sektion → Mit Google verbinden.
Du wirst auf den offiziellen Google-Consent-Screen weitergeleitet, bestätigst, fertig.
Backsta zeigt deinen Google-Account-Namen + den Ziel-Ordner an.

Self-Hosted-Variante (für Power-User mit eigenem Google-Cloud-Project): den OAuth-Modus auf self_hosted umstellen, eigene Client-ID + Client-Secret eintragen. Ist nur nötig wenn du absolut keinen externen OAuth-Flow nutzen willst — was selten Sinn macht.

Cloud-only Mode

Auf Hostings mit knappem Disk-Quota (z.B. 5 GB Disk, 8 GB Backup-Bedarf) läuft das normale Backup nicht durch — die ZIP wird lokal gebaut bevor sie hochgeladen wird.

Tab Sicherheit → Cloud-only Mode aktivieren:

Backup wird direkt in 16-MB-Chunks nach S3/FTP/GDrive gestreamt.
Kein vollständiges Archive landet je auf der lokalen Disk.
Maximaler lokaler Disk-Bedarf: ein Chunk in flight (~16 MB).

Voraussetzung: Mindestens ein Cloud-Storage muss konfiguriert + verifiziert sein. Ohne Storage = Cloud-only kann logischerweise nichts schreiben.

🔄 Wiederherstellung

Voll-Restore

Tab Wiederherstellen. Ein vollständiger Restore überschreibt DB + Files mit dem gewählten Backup-Stand:

Backup wählen (lokal oder von Cloud-Storage).
Verschlüsselte Backups: Passphrase eingeben.
Wiederherstellen klicken → Confirm-Dialog → ggf. Two-Step-Bestätigung per E-Mail.
Backsta erstellt automatisch einen Pre-Restore-Snapshot (24-h-Reue-Fenster), bevor irgendwas überschrieben wird.

Notfall-Restore (Site nicht erreichbar): über WP-CLI gibt es wp backsta restore --file=name.zip. Funktioniert auch wenn das Frontend kaputt ist.

Selective Restore

Statt alles zurückzuspielen, einzelne Tabellen oder Files picken. Tab Wiederherstellen → Selective Restore:

Tabellen-Picker: nur wp_options zurückspielen ohne Posts anzufassen — klassisch wenn nach einer Plugin-Migration die Settings kaputt sind.
File-Picker: einzelne Mediathek-Files zurückspielen ohne den Rest anzufassen.

Use-Case: heute morgen war alles ok, jetzt sind Settings kaputt aber neue Bestellungen sind reingekommen — Selective Restore von wp_options repariert die Settings ohne die neuen Bestellungen zu killen.

Rollback nach Plugin-Version

Plugin-Update hat was kaputt gemacht? Tab Versions-Archiv:

Plugin/Theme in der Liste finden.
Liste der archivierten Versionen aufklappen.
Gewünschte Version → Zurücksetzen.

Backsta legt die alten Files zurück in wp-content/plugins/<slug>/. Die DB wird nicht angefasst — falls das Plugin DB-Migrationen mitgebracht hat, kann es sein dass du die ebenfalls manuell rückgängig machen musst.

Push-to-Staging

Vor einem riskanten Restore in Production: erst auf Staging testen. Tab Staging:

Staging-Site aus letztem Backup erstellen.
Backsta erzeugt unter /wp-content/backsta-staging/<slug>/ eine isolierte Kopie:
- Eigener Tabellen-Prefix (z.B. wpstg_).
- Eigene URL.
- Eigene wp-config.php.
Auf der Staging-Site testen, dann entweder verwerfen oder via Push-to-Production zurückspielen.

Backup hochladen + einspielen

Klassischer Cross-Site-Transport (Production → Staging, lokal entwickeltes Backup → Live, etc.). Tab Wiederherstellen → Card Backup hochladen:

ZIP wählen (backsta-*.zip oder verschlüsselt *.zip.rsv).
Erwarteter SHA-256 (optional aber empfohlen) — kopiere den Hash auf der Quell-Site aus der Backup-Liste (Klick auf den 🔒 …-Chip kopiert die volle 64-Zeichen-Signatur in die Zwischenablage). Backsta verifiziert die Datei beim Empfang via hash_equals — Wire-Tampering oder Korruption im Transit fliegen mit „SHA-256 stimmt nicht überein" raus, bevor das Backup überhaupt angefasst wird.
Hochgeladen wird mit Prefix imported- abgelegt → erscheint in der Backup-Liste, normaler Restore-Pfad.

Magic-Byte-Check: Backsta prüft den ZIP-Header (PK\x03\x04) bzw. den Encryption-Container-Magic (RES2) — Random-Files mit .zip-Endung werden abgewiesen.

Zip-Slip-/Zip-Bomb-Schutz: Vor dem Extract prüft Backsta jeden Eintrag (kein .., keine absoluten Pfade, keine Drive-Letter, kein Compression-Ratio > 1024:1 für Einträge ≥ 1 MiB). Präparierte Backups werden nicht entpackt.

🛡 Validierung & Compliance

Restore Self-Test

Backups die nicht wiederherstellbar sind, sind keine Backups — sind nur große Files auf Disk. Tab Sicherheit → Restore Self-Test aktivieren:

Frequenz: wöchentlich oder monatlich.
Backsta nimmt das letzte Backup, macht einen Dry-Run-Restore in einer Sandbox, validiert SQL-Struktur + ZIP-Konsistenz + File-Liste.
Bei Fund: rote Markierung im Dashboard plus Failure-Notify per E-Mail.

Findet stille Korruption (defekte ZIPs, kaputte SQL-Dumps) bevor du im Ernstfall feststellst dass der Restore nicht klappt.

Backup Re-Verify (sha256)

Tab Sicherheit → Backup Re-Verify:

Wöchentlicher sha256-Check über alle gespeicherten Backups (lokal + S3 + FTP + GDrive).
Vergleicht den heutigen Hash gegen den im Manifest hinterlegten Hash beim Anlegen.
Erkennt: Bit-Flip auf Disk, abgeschnittene Storage-Sync, Null-Byte-Files (häufig auf flaky FTP-Verbindungen).

Bei Fund: Backup wird im UI rot markiert, Failure-Notify, plus der nächste Run schreibt zusätzlich ein neues Voll-Backup damit du nicht ohne valides Backup dastehst.

GPG / HMAC Signatur

Für Compliance-Audits (DSGVO, ISO 27001, SOC 2) brauchst du nachweisbare Backup-Provenance — also dass das Backup wirklich von dir kommt und nicht unterwegs verändert wurde. Tab Sicherheit → GPG / HMAC Signatur:

GPG-Modus: detached .asc-Signatur pro Backup, gegen einen GPG-Key auf deinem Server. Höchste Compliance-Stufe.
HMAC-Modus: HMAC-SHA256 mit einem Shared-Secret. Einfacher aufzusetzen, fast überall verfügbar.
Auto: nimmt GPG wenn verfügbar, sonst HMAC.

Die Signaturen liegen neben den ZIPs als name.zip.asc oder name.zip.hmac — sind unabhängig verifizierbar mit Standard-Tools (gpg, openssl).

Audit-Log (Tab „Protokolle")

Jedes Backup, jeder Restore, jede Settings-Änderung wird protokolliert mit Timestamp, User, IP, Aktion + Ergebnis.

Tab Protokolle zeigt die letzten 500 Einträge filterbar nach Level (info, warn, error).
Export als CSV für Compliance-Reports.
Logs werden im DB-Option-Store gehalten — keine externen Log-Server, keine PII die irgendwo extern landet.

🩺 Troubleshooting

Backup bricht nach 30 / 60 / 90 Sekunden ab

Klassisches PHP-Time-Limit. Backsta verarbeitet chunked und sollte das eigentlich nicht hitten — wenn doch:

Im wp-config.php testweise set_time_limit( 300 ) setzen.
Inkrementell oder Differential aktivieren — kürzere Runs.
Auf shared Hosting eventuell auf Cloud-only Mode umsteigen — kürzere DB-Lock-Zeiten.

„WP-Cron läuft nicht" — Schedule wird ignoriert

WordPress feuert Cron-Tasks nur bei Page-Visits. Auf stillen Sites verspätet sich der Schedule um Stunden / Tage. Lösung:

System-Cron auf wp-cron.php einrichten:

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null

Im wp-config.php: define( 'DISABLE_WP_CRON', true ); — sonst läuft es doppelt.

S3-Upload schlägt fehl mit 403 / SignatureDoesNotMatch

Check Access-Key + Secret-Key — exakt aus dem AWS-Console kopiert (kein Whitespace).
IAM-Policy: s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject für diesen Bucket.
Server-Zeit muss korrekt sein (NTP) — S3-Signaturen haben einen 15-min-Drift-Toleranz, danach: 403.

„Versions-Archiv ist leer" obwohl ich Plugins update

In Backsta v1.1.5 gefixt: vorher hat Versions-Archiv sich selbst übersprungen wenn Pre-Update-Auto-Backup aktiv war. Auf v1.1.5+ updaten — danach werden bei jedem Plugin/Theme-Update wieder Versionen archiviert.

Restore klappt nicht — „kaputtes ZIP"

Erst sha256 verifizieren (Tab Backups → Eintrag → Prüfen).
Wenn Hash matched aber ZIP trotzdem kaputt: Disk-Korruption, weiche Storage-Probleme.
Pre-Restore Self-Test sollte das vorher gefangen haben — falls noch nicht aktiviert: jetzt aktivieren.

Settings sind nach Plugin-Update verschwunden

Sollte ab v1.1.5 nicht mehr passieren — ältere Versionen hatten in seltenen Update-Pfaden eine Settings-Wipe-Race-Condition. Falls trotzdem: einmalig komplett neu konfigurieren, dann unter Sicherheit → Daten beim Deinstallieren sicherstellen dass der Toggle aus ist.