# Altsystem wiederherstellen (Shopware 6.6.10.2, Produktionsverbund)

Diese Anleitung gehört zum Paket, das `dev/deploy/altsystem-export.sh` erzeugt.
Sie beschreibt, wie der Stand des bisherigen Shops wieder in Betrieb geht –
entweder auf demselben Verbund oder auf frischen Maschinen.

## Was der Verbund ist

| Rolle | Host | Adresse | Ausstattung |
| --- | --- | --- | --- |
| Frontend 1 | WEB-SRV-1 | 10.0.1.1 (intern; oeffentlich seit 23.09. nur fuer 94.31.93.15 per SSH) / 10.0.1.1 | 2 CPU, 3 GB, 75 GB; nginx, PHP 8.3-FPM, Shopware-Worker + Scheduler, Laravel-App `stores`, `gutschein` |
| Frontend 2 | WEB-SRV-2 | 46.225.226.85 / 10.0.1.2 | 2 CPU, 3 GB, 75 GB; nginx, PHP 8.3-FPM (keine Worker) |
| Datenbank | DB-SRV-1/2/3 | 10.0.3.1–3 | je 8 CPU, 15 GB, 301 GB; MariaDB 10.11 als **Galera-Cluster** (3 Knoten, multi-master) |
| Cache/Session | REDIS-SRV-1 | 10.0.2.1 | 2 CPU, 3 GB |
| Medien | Hetzner Object Storage | `nbg1.your-objectstorage.com` | Bucket `riccardo-sware-media` (öffentlich), `riccardo-sware-private` |

TLS und Client-IP kommen von einem Load Balancer vor den Frontends; nginx hört
auf Port 80 als `default_server` und übernimmt `X-Forwarded-*`.

## Reihenfolge

1. **Datenbank**
   ```bash
   # auf einem Galera-Knoten, der Cluster muss "Primary/Synced" sein
   zcat shopware-<stempel>.sql.gz | mariadb
   zcat stores_website-<stempel>.sql.gz | mariadb
   mariadb -e 'show status like "wsrep_cluster_size"'   # muss 3 sein
   ```
   Der Dump enthält `CREATE DATABASE` (`--databases`) und ersetzt die Datenbank
   vollständig. Benutzer `shopware_ricc` und `sstuser` liegen in `mysql.user`
   und werden vom Dump **nicht** angefasst – bei frischen Maschinen neu anlegen
   (Rechte siehe `system/mariadb-db1.txt`).

2. **Code**
   ```bash
   cd /var/www && tar xzf shopware-code-<stempel>.tar.gz     # ergibt shopware/
   tar xzf stores-app-<stempel>.tar.gz                        # ergibt stores/ gutschein/
   cd /var/www/shopware && composer install --no-dev -o       # vendor/ ist nicht im Paket
   chown -R www-data:www-data /var/www/shopware
   ```
   `var/log` und `var/cache` sind absichtlich nicht enthalten. `.env` und
   `.env.local` liegen im Paket – sie enthalten Zugangsdaten für Datenbank und
   Object Storage, das Paket gehört deshalb root und nur root.

3. **Medien**
   Die Medien liegen **nicht** im Paket, sondern im Object Storage (89.122
   Objekte, 47 GB; Verzeichnis in `inventar/objectstorage-inventar.txt`). Der
   Bucket ist der Archivstand: solange er unangetastet bleibt, braucht die
   Wiederherstellung nichts zu kopieren. Auf frischen Buckets:
   ```bash
   aws --endpoint-url https://nbg1.your-objectstorage.com \
       s3 sync s3://riccardo-sware-media s3://<neuer-bucket>
   ```
   Danach `S3_BUCKET_PUBLIC`, `S3_PUBLIC_URL`, `S3_THEME_URL` in `.env.local`
   anpassen.

4. **System**
   Aus `system/<host>-system.txt` übernehmen: nginx-vhosts, PHP-FPM-Pool,
   systemd-Units (`shopware-worker@1/2`, `shopware-scheduler`,
   `riccardo-worker` für die Laravel-App), Paketliste. Danach:
   ```bash
   systemctl daemon-reload
   systemctl enable --now shopware-worker@1 shopware-worker@2 shopware-scheduler riccardo-worker
   ```

5. **Abschluss**
   ```bash
   cd /var/www/shopware
   php bin/console cache:clear
   php bin/console theme:compile
   php bin/console dal:refresh:index
   ```
   Prüfen: Startseite über den Load Balancer, ein Artikel mit Bild (Object
   Storage), Anmeldung im Admin, ein Testauftrag bis zur Zahlungsauswahl.

## Was das Paket nicht leisten kann

- **Lizenzen der Fremd-Plugins** (Klarna, Mollie, VRPay, Pickware DHL, Proxa
  Altersprüfung, Saso-Theme, Swag-Erweiterungen – Liste in
  `inventar/plugins.txt`) hängen am Shopware-Account. Der Code liegt im Paket,
  die Lizenz muss beim Wiederaufbau gültig sein.
- **Redis-Inhalt** (Sessions, Cache) wird nicht gesichert; nach der
  Wiederherstellung müssen sich Kundinnen und Kunden neu anmelden.
- **Load Balancer und DNS** liegen außerhalb der Maschinen und sind nicht Teil
  des Pakets.