Magento-Wartungsskripte in Bash — Deploy, Backup, Cache und Logs

1. Warum Magento-Wartungsskripte in Bash unverzichtbar sind

Ein Magento-Deploy ohne strukturiertes Magento-Wartungsskript in Bash ist fehleranfällig. Die korrekte Deploy-Sequenz für Magento 2 umfasst mindestens zehn Schritte in der richtigen Reihenfolge: Composer-Update, Setup-Upgrade, Compilation, Static-Content-Deploy, Cache-Flush und Permissions-Fix. Wer diese Schritte manuell ausführt, überspringt unter Zeitdruck regelmäßig einzelne davon – was zu Cache-Inkonsistenzen, fehlenden generierten Klassen oder nicht aktualisierten Static Assets führt. Ein Magento-Wartungsskript in Bash macht die Sequenz reproduzierbar und atomar: Entweder laufen alle Schritte durch, oder das Skript bricht ab und meldet präzise, welcher Schritt fehlgeschlagen ist.

Neben dem Deploy sind regelmäßige Backup-, Cache- und Log-Wartungsaufgaben in einer Magento-Produktionsumgebung obligatorisch. Magento-Wartungsskripte für diese Aufgaben laufen als Cron-Jobs und stellen sicher, dass Backups täglich angelegt werden, Logs nicht unbegrenzt wachsen und der Cache nach Schema-Änderungen korrekt geleert wird. Die Shell ist für diese Aufgaben das natürliche Werkzeug: direkt auf dem Server, ohne Abhängigkeiten von externen Systemen und mit vollständiger Kontrolle über die Ausführungsumgebung.

2. Die richtige Deploy-Sequenz in Bash

Die Magento-Deploy-Sequenz hat eine feste Reihenfolge, die nicht verändert werden darf. Ein Magento-Wartungsskript in Bash implementiert diese Sequenz mit explizitem Fehlerabbruch bei jedem Schritt: set -euo pipefail am Skriptanfang stellt sicher, dass ein fehlgeschlagener bin/magento setup:upgrade das gesamte Skript sofort abbricht, statt mit veralteten Datenbank-Schemas weiterzulaufen. Die Reihenfolge ist: zuerst Composer, dann setup:upgrade, dann di:compile, dann CSS-Build, dann statische Dateien löschen, dann setup:static-content:deploy, dann cache:flush.

Ein häufiger Fehler in manuellen Deployments und einfachen Magento-Wartungsskripten: Der Schritt "statische Dateien löschen" (rm -rf var/view_preprocessed/* pub/static/frontend/*) wird vergessen oder an der falschen Stelle ausgeführt. Wenn statische Dateien vor dem neuen setup:static-content:deploy nicht gelöscht werden, liefert Magento alte Assets aus dem Cache und neue Inhalte sind nicht sichtbar. Das Deploy-Skript erzwingt diese Reihenfolge. Außerdem muss der Static-Content-Deploy mit dem korrekten Locale und Theme-Identifier ausgeführt werden – Fehler hier führen zu 404-Fehlern für CSS- und JS-Dateien.

#!/usr/bin/env bash
# magento-deploy.sh — Full Magento 2 deploy sequence with error handling
set -euo pipefail
IFS=$'\n\t'

readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly MAGENTO_ROOT="${MAGENTO_ROOT:-${SCRIPT_DIR}/src}"
readonly DEPLOY_LOCALE="${DEPLOY_LOCALE:-de_DE}"
readonly DEPLOY_THEME="${DEPLOY_THEME:-Mironsoft/default}"
readonly LOG_FILE="/var/log/magento/deploy-$(date +%Y%m%d-%H%M%S).log"

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"; }
die() { log "[ERROR] $*"; exit 1; }

# Redirect all output to log file AND terminal
exec > >(tee -a "$LOG_FILE") 2>&1

log "=== Magento Deploy: $DEPLOY_THEME ($DEPLOY_LOCALE) ==="

# Step 1: Composer install (no dev dependencies in production)
log "[1/7] Composer install"
bin/composer install --no-dev --optimize-autoloader || die "Composer failed"

# Step 2: Database schema and data upgrades
log "[2/7] Setup upgrade"
bin/magento setup:upgrade --keep-generated || die "setup:upgrade failed"

# Step 3: Dependency injection compilation
log "[3/7] DI compile"
bin/magento setup:di:compile || die "di:compile failed"

# Step 4: Build CSS (Tailwind/Hyvä) BEFORE deleting static files
log "[4/7] Build CSS"
bin/npm --prefix "${MAGENTO_ROOT}/app/design/frontend/${DEPLOY_THEME}/web/tailwind" run build \
  || die "CSS build failed"

# Step 5: CRITICAL — delete preprocessed and static files BEFORE deploy
log "[5/7] Delete static files"
rm -rf "${MAGENTO_ROOT}/var/view_preprocessed/"*
rm -rf "${MAGENTO_ROOT}/pub/static/frontend/"*

# Step 6: Static content deploy
log "[6/7] Static content deploy"
bin/magento setup:static-content:deploy "$DEPLOY_LOCALE" \
  -t "$DEPLOY_THEME" -f || die "static-content:deploy failed"

# Step 7: Flush all caches
log "[7/7] Cache flush"
bin/magento cache:flush || die "cache:flush failed"

log "=== Deploy completed successfully ==="

3. bin/magento sicher in Shell-Skripten verwenden

Die Integration von bin/magento in Magento-Wartungsskripte erfordert einige wichtige Regeln. Erstens: Niemals php bin/magento direkt aufrufen – der Wrapper bin/magento setzt Umgebungsvariablen, Container-Kontexte und PHP-CLI-Konfigurationen korrekt. In Docker-Umgebungen (Mark Shust Setup) bedeutet das, dass bin/magento den Befehl im PHP-Container ausführt, während direktes php bin/magento den lokalen PHP-Interpreter verwenden würde – der falsche oder gar nicht existierende. Zweitens: Exit-Codes von bin/magento-Kommandos immer prüfen – viele Magento-Befehle geben Warnungen nach stdout aus, aber Exit-Code 0, auch wenn Probleme aufgetreten sind.

Das Muster für robuste bin/magento-Integration in Magento-Wartungsskripten: Vor kritischen Befehlen mit bin/magento maintenance:enable den Maintenance-Mode aktivieren, den Befehl ausführen, danach den Mode wieder deaktivieren – alles in einem trap-gesicherten Block, der den Maintenance-Mode auch bei Fehlern wieder deaktiviert. Das verhindert, dass ein fehlgeschlagenes Deployment die Seite dauerhaft in den Maintenance-Mode versetzt. Für lange Befehle wie setup:static-content:deploy ist ein Timeout-Wrapper sinnvoll: timeout 1800 bin/magento setup:static-content:deploy bricht nach 30 Minuten ab.

4. Datenbank- und Datei-Backup mit rsync und mysqldump

Ein vollständiges Magento-Backup in Bash besteht aus zwei Komponenten: Datenbankdump und Datei-Backup. Für den Datenbankdump ist bin/mysqldump (im Docker-Wrapper-Kontext) oder direkt mysqldump mit den korrekten Parametern das Werkzeug. Wichtig für Magento: --single-transaction für einen konsistenten Dump ohne Lock, --quick für Streaming bei großen Tabellen. Den Dump direkt per Pipe komprimieren: mysqldump ... | gzip -9 > backup.sql.gz spart Disk-I/O und halbiert die Backup-Größe typischerweise um Faktor 5–10.

Das Datei-Backup mit rsync in Magento-Wartungsskripten folgt einem definierten Ausschluss-Muster. Nicht benötigt werden: var/cache/, var/page_cache/, var/session/, pub/static/ (wird neu deployed), vendor/ (aus Composer reproduzierbar). Nötig sind: app/code/, app/design/, app/etc/ (config), pub/media/ (Produktbilder), var/log/ (optional). Mit rsync --delete --checksum im inkrementellen Modus auf ein Backup-Verzeichnis erzeugt man effiziente Backups, die nur geänderte Dateien übertragen.

#!/usr/bin/env bash
# magento-backup.sh — Database and file backup for Magento 2
set -euo pipefail

readonly MAGENTO_ROOT="${MAGENTO_ROOT:-./src}"
readonly BACKUP_DIR="${BACKUP_DIR:-/var/backups/magento}"
readonly BACKUP_DATE=$(date +%Y%m%d-%H%M%S)
readonly KEEP_DAYS="${KEEP_DAYS:-14}"

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"; }

mkdir -p "${BACKUP_DIR}/db" "${BACKUP_DIR}/files"

# Database backup — single transaction for consistency, piped to gzip
log "Starting database backup..."
DB_FILE="${BACKUP_DIR}/db/magento-${BACKUP_DATE}.sql.gz"

bin/mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  magento 2>/dev/null \
  | gzip -9 > "$DB_FILE"

DB_SIZE=$(du -sh "$DB_FILE" | cut -f1)
log "Database backup: $DB_FILE ($DB_SIZE)"

# File backup with rsync — exclude reproducible/cache directories
log "Starting file backup..."
FILES_DIR="${BACKUP_DIR}/files/${BACKUP_DATE}"
mkdir -p "$FILES_DIR"

rsync -a --checksum --delete \
  --exclude='var/cache/' \
  --exclude='var/page_cache/' \
  --exclude='var/session/' \
  --exclude='var/view_preprocessed/' \
  --exclude='pub/static/' \
  --exclude='vendor/' \
  --exclude='.git/' \
  "${MAGENTO_ROOT}/" "${FILES_DIR}/"

FILES_SIZE=$(du -sh "$FILES_DIR" | cut -f1)
log "File backup: $FILES_DIR ($FILES_SIZE)"

# Cleanup old backups
log "Cleaning backups older than ${KEEP_DAYS} days..."
find "${BACKUP_DIR}/db" -name "*.sql.gz" -mtime +"$KEEP_DAYS" -delete
find "${BACKUP_DIR}/files" -maxdepth 1 -type d -mtime +"$KEEP_DAYS" \
  -exec rm -rf {} + 2>/dev/null || true

log "Backup completed successfully"

5. Cache-Management: Flush, Warm-up und selektive Invalidierung

Magento-Cache-Management in Bash-Wartungsskripten geht über ein einfaches bin/magento cache:flush hinaus. Das vollständige Cache-Management umfasst: selektive Cache-Typ-Invalidierung (nur bestimmte Cache-Typen leeren), Cache-Status prüfen, nach dem Flush bestimmte Seiten warm-upen um den First-Request-Overhead zu reduzieren. Das Muster bin/magento cache:clean config full_page leert nur Konfigurations- und Seiten-Cache, ohne den Block-Cache und Generated-Cache anzufassen – das ist nach Konfigurationsänderungen ausreichend und deutlich schneller als ein vollständiger Flush.

Für den Cache-Warm-up nach einem Deploy ist ein einfaches Bash-Wartungsskript mit curl und einer URL-Liste das gebräuchlichste Muster. Das Skript ruft die wichtigsten Seiten (Homepage, Kategorieseiten, Bestseller-Produktseiten) per HTTP ab und primes so den Varnish- oder Magento-Page-Cache. Mit curl -s -o /dev/null -w "%{http_code} %{time_total}s %{url_effective}\n" erhält man gleichzeitig Status-Code und Ladezeit als Feedback. Paralleler Warm-up mit & und Job-Kontrolle reduziert die Warm-up-Zeit auf einen Bruchteil des sequenziellen Ansatzes.

6. Static Content Deploy: Optimierung und Fehlerbehandlung

Der setup:static-content:deploy-Schritt ist typischerweise der zeitintensivste Teil eines Magento-Deployments. In Magento-Wartungsskripten kann er durch parallele Verarbeitung erheblich beschleunigt werden: bin/magento setup:static-content:deploy --jobs 4 nutzt 4 parallele Worker. Für Multi-Locale-Shops mit mehreren Sprachen und Themes ist die Parallelisierung kritisch – ohne sie kann dieser Schritt 10–20 Minuten dauern. Ein weiterer Trick: Mit --strategy compact werden gemeinsame Assets nur einmal deployed statt für jedes Theme/Locale kopiert.

Fehlerbehandlung beim Static-Content-Deploy in Magento-Wartungsskripten ist wichtig, weil dieser Schritt bei fehlenden Abhängigkeiten oder Layout-XML-Fehlern fehlschlagen kann, ohne einen Non-Zero-Exit-Code zurückzugeben. Das Muster: Nach dem Deploy prüfen, ob die erwarteten CSS-Dateien tatsächlich existieren. test -f "${MAGENTO_ROOT}/pub/static/frontend/${DEPLOY_THEME}/${DEPLOY_LOCALE}/css/styles-m.css" verifiziert, dass der Deploy erfolgreich war. Wenn die Datei fehlt, schlägt das Skript mit einem klaren Fehler fehl, bevor der Cache geflusht wird.

7. Log-Rotation für Magento-Logs

Magento erzeugt in var/log/ eine Vielzahl von Logdateien: system.log, exception.log, debug.log, magento.log und viele modulspezifische Logs. Ohne Magento-Log-Rotation in Bash wachsen diese Dateien unbegrenzt – exception.log-Dateien von mehreren Gigabyte sind in ungewarteten Shops keine Seltenheit. Das Standard-Tool logrotate mit einer Magento-spezifischen Konfiguration ist die einfachste Lösung. Ergänzend ist ein Magento-Wartungsskript für die tägliche Analyse der Logs sinnvoll: Wie viele Exceptions gab es gestern? Gibt es neue Exception-Typen?

Das Bash-Muster für manuelle Log-Rotation als Alternative zu logrotate: Die aktuellen Logdateien werden mit Datumsstempel umbenannt (mv system.log "system.$(date +%Y%m%d).log"), dann komprimiert (gzip), eine neue leere Datei angelegt und der Magento-Prozess kann ohne Restart weiterschreiben. Für Magento in Docker-Containern ist logrotate innerhalb des Containers oder eine Volume-gemountete logrotate-Konfiguration auf dem Host die sauberere Lösung. Das Magento-Wartungsskript ergänzt die Rotation um eine automatische Auswertung: Neue Exceptions seit dem letzten Lauf werden extrahiert und im Monitoring-Log festgehalten.

#!/usr/bin/env bash
# magento-log-maintenance.sh — Log rotation and analysis for Magento 2
set -euo pipefail

readonly MAGENTO_ROOT="${MAGENTO_ROOT:-./src}"
readonly LOG_DIR="${MAGENTO_ROOT}/var/log"
readonly ARCHIVE_DIR="${LOG_DIR}/archive"
readonly MAX_SIZE_MB="${MAX_SIZE_MB:-100}"
readonly KEEP_DAYS="${KEEP_DAYS:-30}"

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"; }

mkdir -p "$ARCHIVE_DIR"

# Rotate oversized Magento logs
for logfile in "${LOG_DIR}"/*.log; do
  [[ -f "$logfile" ]] || continue

  size_mb=$(( $(stat -c%s "$logfile") / 1024 / 1024 ))
  filename=$(basename "$logfile")

  if (( size_mb > MAX_SIZE_MB )); then
    archive="${ARCHIVE_DIR}/${filename%.log}.$(date +%Y%m%d-%H%M%S).log.gz"
    log "Rotating $filename (${size_mb}MB) -> $archive"

    # Atomic rotate: copy, compress, truncate (don't delete — PHP keeps fd open)
    cp "$logfile" "${logfile}.rotating"
    gzip -9 "${logfile}.rotating"
    mv "${logfile}.rotating.gz" "$archive"
    # Truncate instead of delete — active PHP process keeps file descriptor
    : > "$logfile"
  fi
done

# Analyze exceptions from last 24 hours
echo ""
echo "=== Exception Summary (last 24h) ==="
SINCE=$(date -d '-24 hours' '+%Y-%m-%d %H:%M:%S')
if [[ -f "${LOG_DIR}/exception.log" ]]; then
  grep "^\[$(date +%Y)" "${LOG_DIR}/exception.log" \
    | awk -v since="$SINCE" '$0 >= "[" since { print }' \
    | grep -oP "(?<=: )[A-Za-z\\\\]+Exception[^\\n]*" \
    | sort | uniq -c | sort -rn | head -10 \
    || echo "No exceptions in last 24h"
fi

# Clean archived logs older than KEEP_DAYS
find "$ARCHIVE_DIR" -name "*.log.gz" -mtime +"$KEEP_DAYS" -delete
log "Cleanup done — removed archives older than ${KEEP_DAYS} days"

8. Maintenance-Mode sicher setzen und zurücknehmen

Der Magento-Maintenance-Mode ist während Deployments unverzichtbar, um Kunden keine teilweise aktualisierten Seiten zu zeigen. In Magento-Wartungsskripten in Bash muss das Aktivieren und Deaktivieren des Maintenance-Modes immer in einem trap-gesicherten Muster erfolgen: Der trap-Handler registriert bin/magento maintenance:disable für den EXIT-Signal, sodass der Mode auch bei einem Skript-Fehler automatisch deaktiviert wird. Ohne diesen trap riskiert man, dass ein fehlgeschlagenes Deploy-Skript die Seite dauerhaft in den Maintenance-Mode versetzt.

Für Zero-Downtime-Deployments mit IP-Whitelisting bietet Magento die Option, bestimmte IPs vom Maintenance-Mode auszunehmen. Das Magento-Wartungsskript aktiviert den Maintenance-Mode mit Whitelisting für die Staging-IP (bin/magento maintenance:enable --ip=STAGING_IP), führt das Deployment durch und deaktiviert den Mode danach. So kann das Ergebnis direkt im Browser verifiziert werden, bevor alle Nutzer die neue Version sehen. Das Skript dokumentiert außerdem die Maintenance-Fenster in einer Log-Datei für spätere Auswertungen.

9. Magento-Wartungsaufgaben im Vergleich

Die verschiedenen Magento-Wartungsaufgaben in Bash haben unterschiedliche Ausführungsfrequenzen, Risikoprofile und Automatisierungsgrade. Die folgende Übersicht hilft bei der Priorisierung der Skript-Entwicklung.

Die höchste Priorität haben Deploy-Skripte und Datenbank-Backups, da Fehler dort direkt Produktionsauswirkungen haben. Log-Rotation und Datei-Backup sind regelmäßige Wartungsaufgaben mit niedrigerem Akutheitsgrad, aber langfristig ebenso kritisch. Cache-Management-Skripte lösen konkrete Kundenprobleme nach Deployments und Konfigurationsänderungen.

10. Zusammenfassung

Magento-Wartungsskripte in Bash machen den Unterschied zwischen fehleranfälligen manuellen Deployments und zuverlässiger Automatisierung. Die Deploy-Sequenz in einem Bash-Skript mit set -euo pipefail und expliziter Schrittreihenfolge verhindert die häufigsten Deploy-Fehler: vergessenes Static-File-Löschen, fehlende DI-Compilation und falschen Cache-State nach dem Deployment. bin/magento wird niemals direkt per php bin/magento aufgerufen, sondern immer über den Wrapper, der den richtigen Ausführungskontext sicherstellt.

Täglich laufende Magento-Wartungsskripte für Backup, Log-Rotation und Cache-Analyse schützen die Produktionsumgebung langfristig: Datenbank-Backups mit --single-transaction und Pipe-Komprimierung, rsync-Datei-Backups mit sinnvoller Ausschlussliste, Log-Rotation durch Truncating statt Deleting für laufende PHP-Prozesse und automatische Exception-Reports für proaktives Monitoring. Diese Skripte zusammen bilden eine vollständige Magento-Operations-Automatisierung.

11. FAQ: Magento-Wartungsskripte in Bash