Kirby CMS absichern

Git-Backup für Content und Code

Wer Kirby CMS produktiv betreibt, steht früher oder später vor der Frage: Wie sichere ich meine Daten zuverlässig? Da Kirby ohne Datenbank arbeitet, liegen alle Inhalte als Dateien im content/-Verzeichnis – ein eleganter Ansatz, der aber ein durchdachtes Backup-Konzept erfordert. Git ist dafür eine naheliegende Lösung.

Zwei Repos, zwei Aufgaben

Das Backup-Konzept teilt sich sinnvollerweise in zwei separate Git-Repositories auf:

Repository 1: Content-Backup
Das Plugin thathoff/kirby-git-content übernimmt die automatische Versionierung des content/-Ordners. Bei jeder Änderung im Panel – neuer Artikel, geändertes Bild, aktualisierte Seite – wird automatisch ein Commit erstellt und zu GitHub gepusht. Das Plugin wird per Composer installiert:

composer require thathoff/kirby-git-content

In der config.php bzw. der domain-spezifischen Config wird es aktiviert:

'thathoff.git-content' => [
    'commit' => true,
    'push'   => true,
    'pull'   => true,
],

Repository 2: Code-Backup
Templates, Plugins, Konfigurationsdateien und Assets liegen außerhalb des content/-Ordners und werden vom Plugin nicht erfasst. Für diese Dateien wird ein zweites Git-Repository im Hauptverzeichnis der Kirby-Installation angelegt. Da sich dieser Bereich selten ändert, reicht ein täglicher Cronjob:

0 2 * * * cd /var/www/kirby && git add . && git commit -m "Daily backup $(date +%Y-%m-%d)" && git push origin main

SSH-Keys für www-data

Da der Webserver unter dem Benutzer www-data läuft, benötigt dieser eigene SSH-Keys für die Authentifizierung bei GitHub. Da www-data kein Home-Verzeichnis besitzt, wird das .ssh-Verzeichnis manuell angelegt:

mkdir -p /var/www/.ssh
chown www-data:www-data /var/www/.ssh
chmod 700 /var/www/.ssh

Da GitHub Deploy Keys nicht für mehrere Repositories gleichzeitig verwendet werden können, braucht jedes Repo einen eigenen Key:

sudo -u www-data ssh-keygen -t ed25519 -C "kirby-content" -f /var/www/.ssh/id_ed25519 -N ""
sudo -u www-data ssh-keygen -t ed25519 -C "kirby-site" -f /var/www/.ssh/id_ed25519_site -N ""

Damit SSH weiß, welcher Key für welches Repository gilt, wird eine ~/.ssh/config angelegt:

Host github-content
    HostName github.com
    User git
    IdentityFile /var/www/.ssh/id_ed25519

Host github-site
    HostName github.com
    User git
    IdentityFile /var/www/.ssh/id_ed25519_site

Die Remote-URLs der Repositories werden entsprechend angepasst:

git remote set-url origin git@github-content:benutzername/kirby-content.git
git remote set-url origin git@github-site:benutzername/kirby-site.git

.gitignore nicht vergessen

Für das Code-Repository ist eine saubere .gitignore wichtig, um den content/-Ordner (hat sein eigenes Repo), den vendor/-Ordner (wird per Composer verwaltet) und temporäre Dateien auszuschließen:

content/
vendor/
storage/
.env

nginx absichern

Da das Git-Repository direkt im Webroot liegt, muss nginx den Zugriff auf .git blockieren:

location ~ /\.git {
    deny all;
    return 404;
}

Fazit

Mit diesem Setup ist Kirby auf zwei Ebenen abgesichert: Inhalte werden bei jeder Änderung automatisch versioniert, der Code täglich gesichert. GitHub übernimmt die Speicherung kostenlos bis 1 GB – für eine typische Kirby-Installation mit moderatem Bildeinsatz reicht das problemlos. Wer auf Nummer sicher gehen will, schließt große Mediendateien per .gitignore aus dem Content-Repo aus und verwaltet sie separat.