# BackUp - Produktivsysteme

<main id="bkmrk-dokumentation-backup"><header><div><div class="badge">Dokumentation</div></div># Backup‑Dokumentation (3‑2‑1)

<div><div class="meta">Organisation: **IT‑TEAM** · Version: **1.1** · Gültig ab: **07.10.2025** · Zeitzone: **Europe/Berlin**</div></div><div class="meta" style="text-align: right;">Eigentümer: **IT‑Leitung**  
Kontakt: <span class="pill">Team‑Channel IT</span> <span class="pill">it@…</span></div></header><section class="toc">### Inhalt

1. [Ziel &amp; Geltungsbereich](#bkmrk-ziel-%26-geltungsberei)
2. [3‑2‑1 Prinzip](#bkmrk-3%E2%80%912%E2%80%911-prinzip-%28umges)
3. [Backup‑Ziele](#bkmrk-backup%E2%80%91ziele-rpo%3A-%E2%89%A4-)
4. [Backup‑Quellen &amp; Ziele](#bkmrk-backup%E2%80%91quellen-%26-zie)
5. [Sicherungsarten &amp; Zeitplan](#bkmrk-sicherungsarten-%26-ze)
6. [Aufbewahrungsrichtlinien](#bkmrk-aufbewahrungsrichtli)
7. [QNAP‑Ordnerstruktur](#bkmrk-qnap%E2%80%91ordnerstruktur-)
8. [Rollen &amp; Verantwortlichkeiten](#bkmrk-rollen-%26-verantwortl)
9. [Zugangsdaten &amp; Schlüsselmaterial](#bkmrk-zugangsdaten-%26-schl%C3%BC)
10. [Monitoring, Berichte &amp; Eskalation](#bkmrk-monitoring%2C-berichte)
11. [Wiederherstellung (Restore)](#bkmrk-wiederherstellung-%28r)
12. [Restore‑Test‑Checkliste](#bkmrk-restore%E2%80%91test%E2%80%91checkli)
13. [Verfahren (operativ)](#bkmrk-verfahren-%28operativ%29)
14. [Sicherheit &amp; Compliance](#bkmrk-sicherheit-%26-complia)
15. [Kapazitäts‑ &amp; Lifecycle‑Management](#bkmrk-kapazit%C3%A4ts%E2%80%91-%26-lifecy)
16. [Änderungskontrolle &amp; Versionierung](#bkmrk-%C3%84nderungskontrolle-%26)
17. [Anhänge](#bkmrk-anh%C3%A4nge-a1%3A-verteile)

</section><section id="bkmrk-ziel-%26-geltungsberei">## Ziel &amp; Geltungsbereich

Diese Dokumentation beschreibt Aufbau, Betrieb und Kontrolle der Backup‑Strategie nach dem 3‑2‑1‑Prinzip für die IT‑Infrastruktur. Sie gilt für alle produktiven Systeme (Server, Dienste, Konfigurationen, Shares) der Organisation.

</section><section id="bkmrk-3%E2%80%912%E2%80%911-prinzip-%28umges">## 3‑2‑1 Prinzip (umgesetzt)

- **3 Kopien**: Produktivdaten + mindestens zwei unabhängige Sicherungskopien.
- **2 Medientypen/Orte**: QNAP‑NAS (2 Systeme), externe Wechselmedien (3 Festplatten), Windows‑Backup‑Server (Veeam), Linux‑Backup‑Server (immutable).
- **1 Kopie extern/offline**: Wöchentliche Sicherung auf externe Festplatten (Wechselbetrieb).

</section><section id="bkmrk-backup%E2%80%91ziele-rpo%3A-%E2%89%A4-">## Backup‑Ziele

- **RPO:** ≤ 24 h (tägliche Sicherungen).
- **RTO:** systemabhängig; Priorität laut Notfallbetrieb (siehe Ordnerstruktur QNAP).
- **Integrität &amp; Unveränderlichkeit:** Linux‑Backup‑Server mit immutable‑Speicher.

</section><section id="bkmrk-backup%E2%80%91quellen-%26-zie">## Backup‑Quellen &amp; Ziele

### Quellen (Beispiele)

<div class="grid cols-2"><div>- Active Directory (Domänencontroller)
- Applikations‑/Applikation‑Server
- File‑Server (Shares, Berechtigungen)
- Terminalserver
- Hilfssysteme: Printserver, Schließanlage

</div><div>  
</div></div>### Ziele / Speicherorte

<div class="grid cols-2"><div>1. **QNAP‑NAS A &amp; QNAP‑NAS B**  
    Primäre NAS‑Ziele für tägliche Sicherungen; Ordnerstruktur zur Priorisierung.
2. **Windows‑Server mit Veeam**  
    Führt Sicherungs‑ und Aufbewahrungslogik aus.
3. **Linux‑Server (immutable)**  
    Unveränderlicher Ziel‑Datenspeicher; aktuell ohne automatische Löschung.
4. **Externe Wechselmedien (3× HDD)**  
    Wöchentliche Offline‑Rotation (extern lagerbar).

</div></div></section><section id="bkmrk-sicherungsarten-%26-ze">## Sicherungsarten &amp; Zeitplan

- **Tägliche Sicherungen:** alle Systeme, Start täglich <span class="kbd">20:00</span>.
- **Wöchentliche Sicherung auf externes Medium:** Rotation über 3 Festplatten (HDD1, HDD2, HDD3).
- **Monatliche Vollsicherung:** zusätzlich zu den täglichen Inkrementen/Differentials.
- **Jährliche Vollsicherung (Jahresarchiv):** Langzeitaufbewahrung.

Zeitfenster mit Wartungsfenstern/Batch‑Jobs abstimmen, um Lastspitzen zu vermeiden.

</section><section id="bkmrk-aufbewahrungsrichtli">## Aufbewahrungsrichtlinien

### Standard (alle Server außer Linux‑immutable)

- 7 Tage tagesaktuelle Wiederherstellungspunkte
- 1× pro Monat: Vollbackup (Monatsstand)
- 1× pro Jahr: Vollbackup (Jahresstand)

### Linux‑Backup‑Server (immutable)

- Aktuell ohne Löschung (unbegrenzte Aufbewahrung)
- Kapazität regelmäßig prüfen; perspektivische Lifecycle‑Policy definieren (z. B. GFS/Objekt‑Lock‑Retention)

</section><section id="bkmrk-qnap%E2%80%91ordnerstruktur-">## QNAP‑Ordnerstruktur (Zielablage)

```
/Backups
├─ Notfallbetrieb
│  ├─ ActiveDirectory
│  ├─ ApplikationServer
│  └─ FileServer
├─ Hilfssysteme
│  ├─ Printserver
│  └─ Schliessanlage
└─ Terminalserver
```

**Bedeutung:** Notfallbetrieb (höchste Priorität), Hilfssysteme (unterstützende Dienste), Terminalserver (Benutzer‑Sitzungen).

</section><section id="bkmrk-rollen-%26-verantwortl">## Rollen &amp; Verantwortlichkeiten

- **IT‑Leitung:** Freigabe der Richtlinie, Budget &amp; Kapazität.
- **Backup‑Admin (Veeam/Storage):** Job‑Design, Aufbewahrungen, Rotationen, Monitoring, Berichte.
- **System‑Owner (Workloads):** Funktionsprüfung der Anwendungen, Teilnahme an Restore‑Tests.
- **Security/Compliance:** Immutable‑Schutz, Zugriffskontrollen, Audit‑Bereitschaft.

</section><section id="bkmrk-zugangsdaten-%26-schl%C3%BC">## Zugangsdaten &amp; Schlüsselmaterial

**Ablage:** Passbolt. **Prinzip:** Need‑to‑Know, Vier‑Augen‑Prinzip. **Achtung:** Keine Zugangsdaten in dieser Dokumentation hinterlegen.

</section><section id="bkmrk-monitoring%2C-berichte">## Monitoring, Berichte &amp; Eskalation

- Statusberichte werden **täglich** an die **IT‑Mitarbeiter** gesendet und **täglich geprüft**.
- Prüfkriterien: Job‑Erfolg/Fehler, Dauer/Throughput, Änderungsrate, Kapazität, Replikations‑/Immutable‑Status.
- Eskalation: ITSM‑Ticket, On‑Call/Backup‑Admin, Sofortmaßnahmen bei Notfallbetrieb.

</section><section id="bkmrk-wiederherstellung-%28r">## Wiederherstellung (Restore)

- Regelmäßige Tests: **vierteljährlich** (quartalsweise) Stichproben‑Restores.
- Umfang: mind. je ein System aus Notfallbetrieb, Hilfssysteme, Terminalserver – inkl. Anwendungsprüfung.
- Dokumentation: Ergebnisprotokoll mit RTO/RPO‑Istwerten, Screenshots/Logs, Lessons Learned.
- Ad‑hoc‑Restores: nach Bedarf; dokumentierter Change.
- **Technische Durchführung:** siehe separate Dokumentation „Restore‑Prozessbeschreibung“.

</section><section id="bkmrk-restore%E2%80%91test%E2%80%91checkli">## Restore‑Test‑Checkliste

Diese Checkliste dient der strukturierten Durchführung und Dokumentation der vierteljährlichen Restore‑Tests. Der technische Ablauf ist in einer separaten Dokumentation beschrieben.

<table><thead><tr><th style="width: 3rem;">\#</th><th>Prüfschritt</th><th>Beschreibung</th><th>Verantwortlich</th><th>Ergebnis / Bemerkung</th></tr></thead><tbody><tr><td>1</td><td>Testauswahl</td><td>Auswahl der Systeme gemäß Rotation (Notfallbetrieb, Hilfssysteme, Terminalserver)</td><td>Backup‑Admin</td><td> </td></tr><tr><td>2</td><td>ITSM‑Ticket</td><td>Anlegen des Restore‑Tickets im ITSM inkl. Scope und Risiken</td><td>Backup‑Admin</td><td> </td></tr><tr><td>3</td><td>Restore durchführen</td><td>Durchführung gemäß Prozessbeschreibung (isolierte Testumgebung/Ersatzsystem)</td><td>System‑Owner / Backup‑Admin</td><td> </td></tr><tr><td>4</td><td>Funktionstest</td><td>Dienste starten, AD‑Login, Datenkonsistenz, Applikationschecks</td><td>System‑Owner</td><td> </td></tr><tr><td>5</td><td>RTO/RPO erfassen</td><td>Ist‑Werte dokumentieren (Start/Ende, Wiederanlaufzeit, Datenstand)</td><td>Backup‑Admin</td><td> </td></tr><tr><td>6</td><td>Protokoll</td><td>Restore‑Protokoll inkl. Screenshots, Logs, Hash‑/Integritätschecks</td><td>Backup‑Admin</td><td> </td></tr><tr><td>7</td><td>Review &amp; Abnahme</td><td>Fachlicher/technischer Review, Abnahme durch IT‑Leitung</td><td>IT‑Leitung</td><td> </td></tr><tr><td>8</td><td>Lessons Learned</td><td>Anpassungen an Jobs, Retention, Kapazität, Runbooks ableiten</td><td>Backup‑Admin / IT‑Leitung</td><td> </td></tr></tbody></table>

</section><section id="bkmrk-verfahren-%28operativ%29">## Verfahren (operativ)

### 1) Täglicher Betrieb (Start 20:00)

1. Veeam‑Jobs starten; Linux‑Immutable‑Targets online.
2. Fortschritt/Logs überwachen.
3. Nach Lauf: Statusbericht erzeugen/versenden; Team prüft bis nächsten Arbeitstag 10:00.

### 2) Wöchentliche Offline‑Rotation (3× HDD)

1. Aktive HDD abkoppeln → sicher lagern (Offsite/Brandschutz empfohlen).
2. Nächste HDD anschließen/mounten.
3. Integritätsprüfung (SMART/FS‑Check/Hash‑Checks, sofern verfügbar).
4. Backup planmäßig laufen lassen; Rückmeldung im Wochenreport dokumentieren.

### 3) Monatliche &amp; jährliche Vollbackups

- Per Veeam‑Zeitplänen/Policies.
- Erstellung und Kopie auf sekundäre Ziele überprüfen (QNAP B / Immutable).
- Jahressätze gesondert kennzeichnen.

### 4) Restore‑Test (quartalsweise)

1. Auswahl Testobjekte nach Kritikalität/Rotation.
2. Wiederherstellung in isolierter Testumgebung oder auf Ersatzsystem.
3. Funktions‑/Integritätsprüfung mit Fachbereichen.
4. Protokollierung im Testregister gemäß Checkliste.

</section><section id="bkmrk-sicherheit-%26-complia">## Sicherheit &amp; Compliance

- Immutable‑Ziel schützt gegen Verschlüsselung/Manipulation.
- Rollenbasierte Zugriffe, Protokollierung aktiv.
- Netzsegmentierung des Backup‑Pfads; gehärtete Admin‑Workstations.
- Malware‑/Checksum‑Prüfungen vor/nach Backup‑Fenster (wenn verfügbar).
- Datenschutz &amp; Datenminimierung beachten.

</section><section id="bkmrk-kapazit%C3%A4ts%E2%80%91-%26-lifecy">## Kapazitäts‑ &amp; Lifecycle‑Management

- QNAP/Windows/Immutable‑Speicher wöchentlich prüfen (Trend, Füllstand, Dedupe/Kompression).
- Alerting bei Schwellwerten (z. B. 80/90/95 %).
- Linux‑Immutable: aktuell ohne Löschung → Kapazitäts‑Forecast und ggf. künftige Retention‑Policy definieren.

</section><section id="bkmrk-%C3%84nderungskontrolle-%26">## Änderungskontrolle &amp; Versionierung

- Änderungen an Jobs, Zeiten, Aufbewahrung, Zielen nur per Change‑Prozess (RFC).
- Dokumentation versionieren; Changelog pflegen.

### Changelog

- **1.1 (07.10.2025):** Ergänzung Restore‑Test‑Checkliste.
- **1.0 (07.10.2025):** Erstdokumentation basierend auf aktuellem Betriebsstand.

</section><section id="bkmrk-anh%C3%A4nge-a1%3A-verteile">## Anhänge

- A1: Verteiler „IT‑Mitarbeiter“ für Statusberichte.
- A2: Passbolt‑Eintrag (Ordner/Gruppe) für Backup‑Zugänge (ohne Details in diesem Dokument).
- A3: Restore‑Testprotokoll‑Vorlage (RTO/RPO‑Checkliste).

</section><footer>© IT‑TEAM · Dieses Dokument enthält betriebskritische Informationen. Interne Verwendung.</footer></main>