Rechtstexte, FinalFlux-Überarbeitung, neue Login-Optik, Konto-Löschung-Fix, BTTF-Farbrelaunch

- Rechtsseiten: Impressum-Platzhalter + echte Nutzungsbedingungen/AGB,
  Datenschutz (DSGVO) und Richtlinien; LegalController/ImpressumController,
  Footer app-weit verlinkt, Seiten als permitAll freigegeben.
- FinalFlux: 28 Themen / ~742 Fragen überarbeitet (plausible Distraktoren statt
  Dummy-Antworten, echte Erklärungen) + echte Lehrtexte je Seite;
  Netzwerktopologien mit Inline-SVG-Diagrammen (Stern/Bus/Ring/Mesh/Baum).
- Login/Registrierung als kombiniertes Dual-Panel (Slide-Overlay + Neon-Hover-
  Button), ausgelagert nach auth.css; Register-Duplikat -> /?registerError.
- Konto löschen repariert: @Transactional + Löschen von Spielständen,
  Achievements und Profilbild-Datei (DSGVO Art. 17). Impressum-Zurück-Link
  login-abhängig.
- App-weiter Farb-Relaunch auf "Back to the Future"-Palette: Feuer-Amber primär
  + Flux-Blau sekundär, warmer Glow; Dark/Light bleiben. Spiele-Feedback ohne
  Grün: richtig = Blau + Haken, falsch = Rot + Kreuz (neue Tokens
  --success/--danger/--secondary). Legacy-Cyan in style.css auf Variablen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/main/resources/static/finalflux/systemintegration/backuparten.html

@@ -15,13 +15,103 @@
   <a href="/finalflux" class="back-link">Zurück zu FinalFlux</a>
   <h1>Backuparten</h1>
 
+  <section>
+    <h2>Warum Datensicherung?</h2>
+    <p>
+      Ein <strong>Backup</strong> ist eine zusätzliche Kopie wichtiger Daten, mit der man
+      nach Hardwaredefekten, Bedienfehlern, Schadsoftware oder Diebstahl den Datenbestand
+      wiederherstellen kann. Das Zurückspielen dieser Kopie heißt <strong>Restore</strong>.
+      Entscheidend ist: Ein Backup ist erst dann wirklich vorhanden, wenn die Wiederherstellung
+      auch getestet wurde. Ungetestete Sicherungen sind im Ernstfall oft wertlos.
+    </p>
+    <p class="merksatz"><strong>Merksatz:</strong> Kein Backup ohne erfolgreichen Restore-Test.</p>
+  </section>
+
   <section>
     <h2>Voll, differentiell, inkrementell</h2>
+    <p>
+      Die drei Sicherungsarten unterscheiden sich darin, <em>was</em> gesichert wird und
+      <em>worauf</em> sie sich beziehen. Daraus ergeben sich Unterschiede bei Speicherbedarf,
+      Sicherungsdauer und Restore-Aufwand.
+    </p>
     <ul class="key-list">
-      <li><strong>Vollbackup:</strong> alle Daten. Einfaches Restore, hoher Speicherbedarf.</li>
-      <li><strong>Differentiell:</strong> alles seit dem letzten Vollbackup. Restore: Vollbackup + letztes differentielles Backup.</li>
-      <li><strong>Inkrementell:</strong> nur Änderungen seit dem letzten Backup. Spart Speicher, Restore braucht die Kette.</li>
+      <li><strong>Vollbackup:</strong> sichert alle ausgewählten Daten. Hoher Speicherbedarf
+        und lange Sicherungsdauer, dafür einfachster Restore (nur ein Stand nötig).</li>
+      <li><strong>Differentielles Backup:</strong> sichert alle Änderungen seit dem
+        <em>letzten Vollbackup</em>. Die Sicherungen wachsen bis zum nächsten Vollbackup an.
+        Restore = Vollbackup + letztes differentielles Backup.</li>
+      <li><strong>Inkrementelles Backup:</strong> sichert nur die Änderungen seit der
+        <em>letzten Sicherung</em> (egal ob voll oder inkrementell). Sehr sparsam und schnell,
+        aber der Restore braucht das Vollbackup plus die komplette Kette aller inkrementellen
+        Sicherungen.</li>
     </ul>
+    <p>
+      <strong>Beispiel (Woche):</strong> Sonntag ein Vollbackup, Montag bis Samstag täglich eine
+      Teilsicherung. Bei <em>differentiell</em> enthält jede Sicherung alles seit Sonntag (sie
+      wird Tag für Tag größer), der Restore von Donnerstag braucht nur Sonntag + Donnerstag.
+      Bei <em>inkrementell</em> sichert jeder Tag nur die Änderungen zum Vortag (kleine, schnelle
+      Sicherungen), der Restore von Donnerstag braucht aber Sonntag + Montag + Dienstag +
+      Mittwoch + Donnerstag.
+    </p>
+    <p class="merksatz"><strong>Merksatz:</strong> Inkrementell spart beim Sichern,
+      differentiell spart beim Restore.</p>
+  </section>
+
+  <section>
+    <h2>Generationenprinzip (Großvater-Vater-Sohn)</h2>
+    <p>
+      Das <strong>Generationenprinzip</strong> staffelt Sicherungen über mehrere Zeitebenen,
+      damit man auf verschieden alte Stände zurückgreifen kann und nicht nur den neuesten besitzt.
+    </p>
+    <ul class="key-list">
+      <li><strong>Sohn:</strong> tägliche Sicherung, kurze Aufbewahrung.</li>
+      <li><strong>Vater:</strong> wöchentliche Sicherung, mittlere Aufbewahrung.</li>
+      <li><strong>Großvater:</strong> monatliche Sicherung, lange Aufbewahrung.</li>
+    </ul>
+    <p>
+      So lassen sich auch ältere Fehler korrigieren, die erst spät auffallen, etwa eine vor zwei
+      Wochen versehentlich gelöschte Datei. Medien werden dabei rotiert und wiederverwendet.
+    </p>
+  </section>
+
+  <section>
+    <h2>Die 3-2-1-Regel</h2>
+    <p>
+      Die <strong>3-2-1-Regel</strong> ist eine einfache Faustregel gegen Datenverlust:
+    </p>
+    <ul class="key-list">
+      <li><strong>3</strong> Kopien der Daten (Original + 2 Sicherungen),</li>
+      <li><strong>2</strong> unterschiedliche Speichermedien/-typen (z. B. Festplatte und Band oder Cloud),</li>
+      <li><strong>1</strong> Kopie an einem externen Ort (außer Haus oder offline).</li>
+    </ul>
+    <p>
+      Die externe bzw. getrennte Kopie schützt vor Ereignissen, die den Standort treffen
+      (Brand, Diebstahl, Überspannung) oder das gesamte Netz erfassen (Ransomware). Besonders
+      wirksam gegen Ransomware sind <em>unveränderliche</em> (immutable) oder vollständig
+      vom Netz getrennte Sicherungen.
+    </p>
+  </section>
+
+  <section>
+    <h2>RPO und RTO</h2>
+    <p>
+      Zwei Kennzahlen steuern, wie ein Backup-Konzept ausgelegt sein muss:
+    </p>
+    <ul class="key-list">
+      <li><strong>RPO (Recovery Point Objective):</strong> maximal tolerierbarer
+        <em>Datenverlust</em>, gemessen als Zeitspanne. Er bestimmt den Sicherungsabstand:
+        Bei RPO = 1 Stunde muss mindestens stündlich gesichert werden.</li>
+      <li><strong>RTO (Recovery Time Objective):</strong> maximal tolerierbare
+        <em>Ausfall-/Wiederherstellungszeit</em>. Er bestimmt, wie schnell ein System nach
+        einem Ausfall wieder laufen muss.</li>
+    </ul>
+    <p>
+      <strong>Eselsbrücke:</strong> RP<u>O</u> blickt nach hinten (Wie viele Daten darf ich
+      verlieren?), RT<u>O</u> blickt nach vorn (Wie lange darf der Ausfall dauern?).
+    </p>
+    <p class="merksatz"><strong>Merksatz:</strong> RPO = Datenverlust in Zeit,
+      RTO = Ausfalldauer. Beide leiten sich aus dem Geschäftsrisiko ab und bestimmen die
+      Backup-Strategie.</p>
   </section>
 
   <section>