Einleitung

Dieser Beitrag behandelt Backup, Restore und Upgrade nicht als abstraktes Konzept, sondern als prüfbares Runbook für XWiki mit Datenbank, Attachments, Extensions und Konfiguration.

Testumgebung und Annahmen

Die Beispiele verwenden neutrale Lab-Namen wie wiki.example.test und xwiki01.example.test. Sie zeigen echte Arbeitsschritte, enthalten aber keine produktiven Hostnamen, Zugangsdaten oder internen Pfade.

  • XWiki läuft hinter einem Reverse Proxy mit HTTPS.
  • PostgreSQL wird als Datenbank verwendet.
  • Attachments und XWiki-State liegen in einem persistenten Verzeichnis.
  • Administration erfolgt über die XWiki-Oberfläche und ergänzend über die Shell.

Ablauf als Runbook

  1. Bestandsaufnahme: Datenbank, permanenter Speicher, Extensions, Konfiguration.
  2. Konsistentes Backup erzeugen.
  3. Restore in isolierter Testinstanz durchführen.
  4. Suche, Attachments, Rechte, Mail und Extensions prüfen.
  5. Upgrade erst nach erfolgreichem Restore-Test durchführen.

Was in diesem Teil besonders wichtig ist

Bei Backup, Restore und Upgrade muss der technische Zustand zur Bedienung in der Oberfläche passen. Ein Befehl kann grün sein, während Benutzer trotzdem keine Seite finden, keine Rechte haben oder die Suche unbrauchbar ist.

Vor der Änderung: Baseline schaffen

bash
curl -fsS -o /dev/null -w '%{http_code}\n' https://wiki.example.test/bin/view/Main/
systemctl is-active tomcat postgresql nginx
df -h /srv/xwiki/permanent
  1. Anmelden und rechts oben das Menü öffnen.
  2. Administration wählen.
  3. Links zuerst Users & Rights, Extensions, Search und Mail ansehen.
  4. Danach in den betroffenen Space wechseln und dort Space-Rechte, Seiten und Attachments prüfen.
  5. Zum Schluss mit einem normalen Benutzer testen, nicht nur mit dem Administrator.

Durchführung

Backup und Restore ausführen

bash
install -d -m 0700 /backup/xwiki/$(date +%F)
systemctl stop tomcat
pg_dump -Fc -f /backup/xwiki/$(date +%F)/xwiki.dump xwiki
rsync -aHAX --numeric-ids /srv/xwiki/permanent/ /backup/xwiki/$(date +%F)/permanent/
rsync -aHAX --numeric-ids /etc/xwiki/ /backup/xwiki/$(date +%F)/etc-xwiki/
systemctl start tomcat
bash
createdb -O xwiki xwiki_restore
pg_restore -d xwiki_restore /backup/xwiki/2026-10-10/xwiki.dump
rsync -aHAX /backup/xwiki/2026-10-10/permanent/ /srv/xwiki/permanent/
systemctl restart tomcat

Wie vollständig haben wir getestet?

  • Browser-Oberfläche: Startseite, Administration, Space-Ansicht und Login.
  • Technische Dienste: Tomcat, PostgreSQL, Reverse Proxy und Storage.
  • Funktionale Tests: Suche, Attachments, Rechte, Mail und Extensions.
  • Rollback- oder Restore-Pfad ist beschrieben und einmal praktisch geprüft.

Technische Abnahme

PASS  home page returns HTTP 200
PASS  administrator can open global administration
PASS  normal user sees only intended spaces
PASS  attachment upload and download work
PASS  search finds known page title and attachment
PASS  backup or rollback path is available

Pflichttests

  • Login als Admin und als normaler Benutzer.
  • Navigation zu Administration -> Users & Rights.
  • Navigation zu Administration -> Extensions.
  • Navigation zu Administration -> Search.
  • Anlegen oder Bearbeiten einer Testseite mit Attachment.
  • Abmeldung und erneute Anmeldung prüfen.

Was bedeutet PASS in diesem Test?

PASS bedeutet nicht nur, dass ein Dienst läuft. PASS bedeutet, dass der Benutzerpfad im Browser funktioniert, der technische Zustand plausibel ist und ein zweiter Test mit eingeschränkten Rechten das erwartete Ergebnis liefert.

Stolpersteine

  • Adminrechte werden global gesetzt, obwohl eigentlich Space-Rechte reichen würden.
  • Attachments liegen nicht im persistenten Verzeichnis.
  • Backups sichern die Datenbank, aber nicht Extensions, Konfiguration und Attachments.
  • Die Suche wird nach Restore oder Upgrade nicht geprüft.
  • Screenshots oder Dokumentation enthalten echte interne Hostnamen.

Finaler Health Check

bash
curl -fsS -o /dev/null -w '%{http_code}\n' https://wiki.example.test/bin/view/Main/
systemctl is-active tomcat postgresql nginx
journalctl -u tomcat --since -1h --no-pager | tail -n 80

Checkliste

  • Öffentliche URL und Admin-Zugriff geprüft.
  • Benutzer- und Gruppenmodell dokumentiert.
  • Datenbank, Attachments und Konfiguration im Backup enthalten.
  • Restore- oder Rollback-Test durchgeführt.
  • Suchindex und Mailfunktion geprüft.
  • Keine echten Hostnamen oder Secrets im öffentlichen Beitrag.

Partner-Runbook: Reihenfolge für eigene Umgebungen

  1. Zuerst Lab- oder Staging-System aufbauen.
  2. Dann XWiki-Oberfläche mit Admin und normalem Benutzer durchtesten.
  3. Erst danach SSO, Rechte, Backup und Monitoring produktiv übernehmen.
  4. Jede Änderung mit Browserpfad und Shell-Check abnehmen.

FAQ

Reicht es, wenn XWiki im Browser öffnet?

Nein. Zusätzlich müssen Login, Rechte, Suche, Attachments, Mail und Backup geprüft werden.

Muss jede Installation SSO verwenden?

Nicht zwingend. Produktiv sollte aber klar sein, ob Benutzer lokal, per LDAP, OIDC oder SAML verwaltet werden.

Warum so viel Wert auf Restore legen?

Weil ein Wiki ohne Attachments, Rechte und Extensions nach einem Vorfall zwar startet, aber für Benutzer oft nicht mehr vollständig nutzbar ist.

Fazit

XWiki wird produktionsreif, wenn technische Installation, Bedienung in der Oberfläche, Rechte, Backup und Betrieb zusammen getestet werden. Genau diese Kombination macht die Reihe nachvollziehbar.

Die Befehle sind nur die halbe Arbeit. Entscheidend ist die dokumentierte Abnahme mit echten Benutzerpfaden in XWiki. Die dazugehörige XWiki-Reihe findest du direkt unter dem Beitrag.