Backup und Disaster Recovery: Zustände, Ziele und Wiederanlauf

Ein erfolgreich beendeter Sicherungsjob beweist zunächst nur, dass ein Werkzeug Daten geschrieben hat. Er sagt noch nicht, ob der Sicherungspunkt vollständig, anwendungskonsistent, gegen denselben Ausfall geschützt und innerhalb der vereinbarten Zeit wieder als nutzbarer Dienst herstellbar ist. Backup bezeichnet die wiederherstellbare Kopie eines früheren Zustands; Disaster Recovery umfasst zusätzlich Menschen, Prioritäten, Zielinfrastruktur, Abhängigkeiten, Validierung und die kontrollierte Rückkehr in den Betrieb. NIST trennt deshalb Sicherung, Wiederherstellungsstrategie, Recovery-Verfahren, Tests und laufende Planpflege (NIST SP 800-34 Rev. 1).

Für Messaging-Plattformen ist «die Datenbank» kein vollständiges Schutzobjekt. Ein nutzbarer Zustand kann sich auf Mailbox- oder Blob-Speicher, relationale Metadaten, Transportqueues, Suchindizes, Konfigurationen, Routingregeln, Verzeichnisreferenzen, Zertifikate, private Schlüssel, DNS, Lizenzen und Automatisierung verteilen. Einige Teile sind führend, andere nur Projektionen und wieder andere flüchtige Zustände. Der Recovery-Plan muss für jeden Teil festhalten, ob er zurückgespielt, neu aufgebaut, neu ausgestellt oder bewusst verworfen wird. NIST verlangt neben Benutzerdaten auch Systemzustand, Software, Inventar, Lizenzen und sicherheitsrelevante Dokumentation; PostgreSQL weist beispielsweise ausdrücklich darauf hin, dass WAL-Archivierung seine Konfigurationsdateien nicht mitsichert (NIST SP 800-34 Rev. 1, CP-9, PostgreSQL: Continuous Archiving und PITR).

Das operative Abnahmekriterium lautet daher nicht «Backup gemountet», sondern etwa: Ein externer Absender kann eine Nachricht zustellen, die richtige Policy wird angewandt, die Nachricht erscheint im vorgesehenen Postfach, ist suchbar und beantwortbar, und Monitoring sowie Audit erfassen den Vorgang. NIST nennt erfolgreiche und rechtzeitige Restores, erreichte Recovery-Ziele und wieder verfügbare Benutzer oder Systeme als messbare Recovery-Ergebnisse (NIST SP 800-184, NIST SP 800-184, Recovery Metrics).

Die Erklärung beginnt beim Geschäftsprozess, der nach einem Ausfall wieder funktionieren muss. Daraus entstehen RTO und RPO, danach die passende Sicherungskette; am Ende steht nicht der Backupjob, sondern ein gemessener Restoretest.

Backup ist nicht Hochverfügbarkeit

Backup, Snapshot, Replikation und Hochverfügbarkeit lösen unterschiedliche Fehlerklassen. Microsoft beschreibt Backup und Replikation ausdrücklich als komplementär: Replikation hält eine aktuelle Kopie für den laufenden Betrieb, übernimmt aber auch logische Löschungen oder Beschädigungen; ein zeitgestempeltes Backup ermöglicht den Rücksprung auf einen älteren Zustand (Microsoft Azure Reliability: Redundancy, Replication and Backup).

Ein Snapshot kann ein Baustein der Sicherung sein. Er wird jedoch erst durch Konsistenz, Export oder Replikation in einen unabhängig betriebenen Speicher, Retention, Katalog und Restore-Verfahren zu einer belastbaren Recovery-Quelle. Die Kubernetes-Snapshot-API garantiert beispielsweise selbst keine Anwendungskonsistenz; Anwendungen müssen vor dem Snapshot geeignet vorbereitet werden. Unter Windows übernimmt VSS diese Koordination nur dann, wenn Requester, Writer und Provider korrekt zusammenspielen (Kubernetes: Volume Snapshot und Anwendungskonsistenz, Microsoft: Volume Shadow Copy Service).

MTD, RTO und RPO gehören an Geschäfts- und Systemfunktionen

Die Maximum Tolerable Downtime (MTD) ist die längste Unterbrechung, die der Geschäftsprozess insgesamt toleriert. Die Recovery Time Objective (RTO) beschreibt, wie lange eine konkrete Systemressource ausfallen darf, bevor andere Ressourcen, der unterstützte Prozess oder seine MTD unvertretbar beeinträchtigt werden. Die Recovery Point Objective (RPO) bezeichnet den Zeitpunkt vor dem Ereignis, bis zu dem Daten wiederhergestellt werden müssen. RTO muss typischerweise kürzer als MTD sein, weil nach dem technischen Wiederanlauf noch Daten nachverarbeitet und der Dienst fachlich geprüft werden muss (NIST SP 800-34 Rev. 1, Abschnitt 3.2).

Ein einziges «Mail-RTO» verdeckt relevante Unterschiede. Eine Plattform kann SMTP annehmen, obwohl Benutzerzugriff oder Suche noch nicht verfügbar sind. Ein Gateway kann Nachrichten puffern, obwohl der nachgelagerte Mailboxdienst ausgefallen ist. Umgekehrt ist eine Weboberfläche erreichbar, während Schlüssel, Directory-Lookups oder ausgehende Konnektoren fehlen. Ziele sollten deshalb pro Geschäftsfunktion und Abhängigkeit festgelegt werden.

Sind die Ziele festgelegt, muss der tatsächliche Zustand der Plattform inventarisiert werden. Eine Mailboxdatenbank allein stellt weder Routing, Identitäten, Schlüssel noch Suchindizes wieder her.

Zustandsinventar einer Messaging-Plattform

Eine Sicherungspolitik beginnt mit einem Zustands- und Abhängigkeitsinventar, nicht mit dem Produktkatalog des Backup-Herstellers. Für jeden Zustand werden führende Quelle, Konsistenzmechanismus, RPO, Retention, Schutzdomäne, Wiederherstellungsmethode, Reihenfolge und Prüfschritt dokumentiert. Die Business Impact Analysis von NIST identifiziert kritische Prozesse, Ressourcen und ihre Recovery-Priorität; NIST SP 800-184 ergänzt realistische Szenarien und während der Wiederherstellung neu entdeckte Abhängigkeiten (NIST SP 800-34 Rev. 1, NIST SP 800-184).

Queue-Recovery ist ein Sonderfall. SMTP verlangt, angenommene Verantwortung zuverlässig auszuführen, erlaubt bei Verbindungsabbrüchen aber Situationen, in denen Sender und Empfänger den Abschluss unterschiedlich beurteilen. Ein wieder eingespielter Queue-Zustand kann deshalb Nachrichten erneut zustellen. Die Runbooks benötigen eine definierte Duplikatstrategie, Queue-IDs, Zeitfenster und Empfängerkommunikation; blosses Kopieren eines Spool-Verzeichnisses ist kein normgerechter Restore (RFC 5321, Queuing and Duplicate Messages).

Konsistenz entsteht an der Anwendungsschicht

Ein crash-konsistenter Sicherungspunkt enthält den Zustand, den ein System nach abruptem Stromverlust sehen würde. Dateisystem und einzelne Blöcke können in sich konsistent sein, während zusammengehörige Datenbanken, Blobs und Queues unterschiedliche Zeitpunkte repräsentieren. Ein anwendungskonsistenter Sicherungspunkt koordiniert Schreibpuffer, Transaktionslogs, Checkpoints und gegebenenfalls mehrere Volumes so, dass die Anwendung einen definierten Recovery-Pfad besitzt.

VSS zeigt diese Architektur explizit: Der Backup-Requester fordert die Sicherung an, der anwendungsspezifische Writer stellt einen konsistenten Datensatz bereit, und der Provider erzeugt die Shadow Copy. Exchange stellt dafür einen eigenen VSS Writer bereit; ein Exchange-bewusstes Backup ist deshalb mehr als ein Snapshot seiner Datenbankdateien (Microsoft: Volume Shadow Copy Service, Microsoft: Windows Server Backup für Exchange).

PostgreSQL verwendet ein anderes, aber vergleichbares Recovery-Modell. Ein Base Backup liefert die Ausgangsbasis, eine lückenlose Folge archivierter Write-Ahead-Log-Segmente führt sie bis zum gewünschten Zeitpunkt fort. Ein pg_dump ist ein logischer Export und kein Ersatz für die für PITR erforderliche Base-Backup-/WAL-Kette. Konfigurationsdateien wie postgresql.conf und pg_hba.conf liegen ebenfalls ausserhalb dieser WAL-Recovery und brauchen einen separaten Sicherungsweg (PostgreSQL: Continuous Archiving und PITR).

Für verteilte Produkte muss die Produktdokumentation beantworten, ob Backends unabhängig, als Konsistenzgruppe oder über anwendungseigene Exportfunktionen gesichert werden. Ein gleichzeitiger Storage-Snapshot mehrerer Volumes ist nicht automatisch ein konsistenter Schnitt durch Datenbank, Objektstore, Queue und Suchindex. Der Admin muss die Quelle der Wahrheit und den zulässigen Rebuild-Pfad pro Projektion kennen.

Kapazität und Sicherungsartefakte inventarisieren

Get-Volume | Sort-Object DriveLetter |
  Select-Object DriveLetter, FileSystemLabel, Size, SizeRemaining
Get-ChildItem \\backup.example.ch\mail -File -Recurse |
  Select-Object FullName, Length, LastWriteTime

df -hT
find /backup/mail -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %s %p\n'

Get-Volume und df zeigen die belegte und freie Kapazität. Get-ChildItem und find inventarisieren Artefakte und Zeitstempel. Beides belegt weder Anwendungskonsistenz noch Wiederherstellbarkeit; dafür braucht es Katalog-, Log- und Restore-Nachweise.

Schutzarchitektur: getrennt, isoliert und überprüfbar

Eine belastbare Sicherungskette besitzt mindestens vier voneinander unterscheidbare Rollen:

1. Capture: Anwendung oder Exportfunktion erzeugt einen definierten Zustand.
2. Katalog und Manifest: Backup-ID, Quelle, Zeitpunkt, Softwarestand, benötigte Logs, Schlüsselreferenzen und Prüfsummen machen den Satz auffindbar und überprüfbar.
3. Recovery-Speicher: Versionierte Kopien liegen ausserhalb der primären Fehler- und möglichst auch Administrationsdomäne.
4. Recovery-Control-Plane: getrennte Identitäten, Runbooks, Zielinfrastruktur und Freigaben ermöglichen Wiederherstellung, wenn die Produktion nicht vertrauenswürdig ist.

CIS Control 11 fordert äquivalent geschützte Recovery-Daten, eine isolierte Instanz beispielsweise offline, in der Cloud oder ausserhalb des Standorts sowie regelmässige Restore-Tests. CISA empfiehlt für Ransomware-Szenarien offline oder anderweitig isolierte, verschlüsselte und regelmässig getestete Backups sowie saubere Images und eine getrennte Recovery-Umgebung (CIS Control 11: Data Recovery, CISA: StopRansomware Guide).

Unveränderbarkeit und Isolation sind nicht dasselbe. S3 Object Lock kann bestimmte Objektversionen im WORM-Modell während einer Retention oder eines Legal Hold gegen Löschen und Überschreiben schützen. Governance- und Compliance-Modus besitzen unterschiedliche Umgehungsmöglichkeiten. Das schützt gespeicherte Versionen, beweist aber weder getrennte Zugangsdaten noch einen sauberen Restore-Endpunkt, eine vollständige Anwendungskette oder erreichbare Entschlüsselungsschlüssel (Amazon S3: Object Lock).

Prüfsummen und Manifest kontrollieren

Get-FileHash .\mail-backup-2026-08-08.tar.zst -Algorithm SHA256
Get-FileHash .\mail-backup-2026-08-08.manifest.json -Algorithm SHA256

sha256sum mail-backup-2026-08-08.tar.zst
sha256sum mail-backup-2026-08-08.manifest.json

Get-FileHash und sha256sum erkennen Änderungen an einem Artefakt, wenn der erwartete Hash aus einer vertrauenswürdigen Quelle stammt. Eine Prüfsumme ersetzt keine Authentisierung des Manifests und keine Wiederherstellungsprobe. NIST nennt kryptografische Hashes und digitale Signaturen als Mechanismen zum Integritätsschutz von Backup-Informationen (NIST SP 800-34 Rev. 1, CP-9).

Schlüssel und Secrets sind ein eigener Recovery-Plan

«Alle privaten Schlüssel sichern» ist ebenso falsch wie «Zertifikate kann man neu ausstellen». Entscheidend ist der Verwendungszweck:

• Ein verlorener TLS-Server-Schlüssel kann meist durch ein neues Schlüsselpaar und Zertifikat ersetzt werden; die Umschaltung muss dennoch im RTO liegen, und zugehörige Trust- oder Pinning-Abhängigkeiten sind zu prüfen.
• Ein Entschlüsselungsschlüssel für gespeicherte S/MIME-, OpenPGP- oder Backup-Daten muss so lange verfügbar bleiben, wie der geschützte Chiffretext lesbar sein soll.
• Das Backup eines privaten Signaturschlüssels ist laut NIST im Allgemeinen nicht wünschenswert, weil seine Wiederverwendung die Aussagekraft der Signatur berühren kann; begründete Ausnahmen verlangen besonders sichere Recovery und raschen Ersatz.
• Ein nicht exportierbarer HSM-/KMS-Schlüssel braucht den vom System vorgesehenen Redundanz-, Backup- oder Reprovisionierungsweg. Der Export eines Zertifikats ohne privaten Schlüssel ist kein Schlüsselbackup.
• Der Schlüssel, der das Backup verschlüsselt, darf nicht ausschliesslich innerhalb des verschlüsselten Backups oder der kompromittierten Produktionsdomäne liegen.

NIST fordert eine Entscheidung nach Schlüsseltyp, zugehörige Metadaten, eine Key-Recovery-Policy sowie Vertraulichkeits-, Integritäts-, Verfügbarkeits- und Auditkontrollen für das Recovery-Material. Geht ein Entschlüsselungsschlüssel verloren, kann der Chiffretext nicht mehr in Klartext zurückgeführt werden (NIST SP 800-57 Part 1 Rev. 5, NIST SP 800-57 Part 1 Rev. 5, Key Recovery).

Zeit und Namensauflösung vor dem Restore prüfen

w32tm /query /status
Resolve-DnsName -Type MX example.ch
Resolve-DnsName backup.example.ch

timedatectl status
dig +short MX example.ch
dig +short A backup.example.ch

w32tm und timedatectl kontrollieren die Zeitbasis für Zertifikate, Kerberos, Logs und Recovery-Punkte. Resolve-DnsName und dig zeigen, ob MX-, Service- und Repository-Namen in der Recovery-Zone wie vorgesehen aufgelöst werden. Die DNS-Quelle und ihre Änderungsberechtigung gehören selbst ins Abhängigkeitsinventar.

Ein konsistentes Backup ist erst die Hälfte des Plans. Beim Restore müssen Identität, DNS, Datenbank, Queue, Schlüssel und Anwendungen in einer begründeten Reihenfolge zurückkehren.

Wiederanlauf folgt der Abhängigkeitsgrafik

Eine feste Produktreihenfolge wäre erfunden. Die belastbare Reihenfolge entsteht aus BIA, Ressourceninventar und tatsächlichen Abhängigkeiten. NIST fordert eine priorisierte Liste der Systemressourcen und realistische Testszenarien; NIST SP 800-184 verlangt, während des Restores neu erkannte Abhängigkeiten in die Dokumentation zurückzuführen (NIST SP 800-34 Rev. 1, Recovery Priorities, NIST SP 800-184, Recovery Execution). Für eine typische Messaging-Plattform ergibt sich daraus häufig folgende, vor Ort zu validierende Kette:

1. Ereignis eingrenzen: Ausfall oder Kompromittierung unterscheiden, Beweise erhalten, bekannten sauberen Recovery-Punkt und Freigabe festlegen.
2. Recovery-Control-Plane herstellen: getrennte Admin-Identitäten, MFA, Runbooks, Backup-Katalog und Entschlüsselungszugriff bereitstellen.
3. Grunddienste validieren: Netzwerk, Routing, DNS, Zeit, LDAP oder Kerberos, PKI/KMS und Load Balancer in der Zielzone prüfen.
4. Persistenz wiederherstellen: Objekt-/Mailboxspeicher, Datenbanken und benötigte Transaktionslogs in einem konsistenten Schnitt aufbauen.
5. Anwendung und Policy starten: freigegebene Images, Konfiguration, Secrets, Konnektoren und Rollen einspielen; noch keinen unkontrollierten externen Mailfluss zulassen.
6. Queue und Routing kontrolliert aktivieren: Alter, Empfänger, Retry-Zustand und mögliche Duplikate bewerten; Ein- und Ausgang getrennt freigeben.
7. Projektionen neu bilden: Suchindizes, Caches und Reporting aus führenden Quellen erzeugen und Rebuild-Lag überwachen.
8. Geschäftstransaktion abnehmen: Zustellung, Mailboxzugriff, Suche, TLS, Verschlüsselung, Monitoring und Audit gegen definierte Kriterien testen.

Für ein Sicherheitsereignis reicht «System startet» ausdrücklich nicht. NIST beschreibt die Reconstitution in einen bekannten sicheren Zustand mit sicheren Parametern, Patches, Konfiguration, vertrauenswürdiger Software, bekannt sauberem Backup und vollständigem Test. CIS formuliert dasselbe Ziel als Wiederherstellung in einen «pre-incident and trusted state» (NIST SP 800-34 Rev. 1, CP-10, CIS Control 11: Data Recovery).

Recovery-Endpunkte und TLS erreichen

Test-NetConnection backup.example.ch -Port 443 -InformationLevel Detailed
curl.exe --verbose https://backup.example.ch/health

nc -vz backup.example.ch 443
openssl s_client -connect backup.example.ch:443 \
  -servername backup.example.ch -verify_return_error

Test-NetConnection und nc prüfen den TCP-Pfad. curl und openssl s_client zeigen HTTP- beziehungsweise TLS-Verhalten. Ein erreichbarer Health-Endpunkt belegt nur die Control Plane, nicht die Lesbarkeit sämtlicher Backup-Sätze.

Der Wiederanlauf ist erst abgeschlossen, wenn ein Benutzer oder eine Gegenstelle den Dienst tatsächlich verwenden kann. Ein erfolgreich gelesenes Backupmedium ist dafür kein ausreichender Nachweis.

Restore-Tests messen den Dienst, nicht das Medium

Ein vollständiger Test läuft in einer isolierten Zielumgebung mit dokumentiertem Startpunkt, Zeitmessung und Abnahmekriterien. Er prüft mindestens:

• ob Katalog, Credentials, Entschlüsselungsschlüssel und Artefakte ohne die Produktion erreichbar sind;
• ob ein kompatibles Zielsystem aus vertrauenswürdigen Images bereitgestellt werden kann;
• ob Base Backup, Transaktionslogs, Blob-Speicher und Konfiguration denselben fachlichen Stand ergeben;
• ob Queues kontrolliert verarbeitet und Duplikate erkannt werden;
• ob Identität, DNS, TLS, Mailfluss, Mailboxzugriff, Suche und Monitoring funktionieren;
• ob gemessener Datenverlust und gemessene Wiederanlaufzeit RPO und RTO einhalten;
• ob der Dienst nach Sicherheitsereignissen als vertrauenswürdig freigegeben werden kann.

CIS Control 11.5 bewertet eine Stichprobe wiederhergestellter und danach tatsächlich funktionsfähiger Backups. NIST SP 800-184 misst erfolgreiche und rechtzeitige Restores und fordert realistische Szenarien, Nachbesprechung und Planverbesserung (CIS Control 11: Test Data Recovery, NIST SP 800-184). Die Testfrequenz folgt Risiko, Änderungsrate und Vorgaben; ein jährlicher Volltest kann durch häufigere automatisierte Stichproben und komponentenbezogene Restores ergänzt werden, darf aber nicht durch erfolgreiche Jobstatistiken ersetzt werden.

Listener und Speicherzustand nach dem Restore

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess
Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining

ss -lntup
df -hT

Get-NetTCPConnection und ss zeigen lokale Listener und zugehörige Prozesse. Get-Volume und df zeigen freien Speicher. Die Prüfung muss anschliessend auf Protokollebene weitergehen: Ein Listener auf Port 25 ist noch keine funktionierende SMTP-Transaktion.

Fehlerbilder und passende Recovery-Scope

Ein Ausfall bestimmt, wie weit eine Wiederherstellung greifen muss. Die Tabelle verbindet deshalb das beobachtete Ereignis mit dem kleinsten sinnvollen Recoveryumfang und der Fehlannahme, die dabei besonders häufig entsteht.

Bei einer Kompromittierung muss der bekannte saubere Zeitpunkt nicht der jüngste Sicherungspunkt sein. Neuere Backups können den Angreiferzustand enthalten; ältere können bekannte Schwachstellen oder inkompatible Softwarestände mitbringen. Recovery verbindet deshalb Forensik, Patchstand, Konfigurationsbaseline, Schlüsselrotation und fachliche Datenwiederherstellung. CISA empfiehlt unter anderem saubere «golden images», offline gehaltene Infrastrukturdefinitionen und eine Recovery-Netzzone, damit Systeme nicht während des Wiederaufbaus erneut infiziert werden (CISA: StopRansomware Guide).

Technische Entwicklung

Magnetband wurde Anfang der 1950er-Jahre als schnelles Datenspeichermedium für Rechner eingeführt und bleibt wegen Kosten, Kapazität und physischer Trennbarkeit ein Backup-Medium (IBM: Magnetic Tape). Spätere Sicherungsarchitekturen trennten den logischen Sicherungspunkt zunehmend vom Zielmedium: Datenbanken kombinierten Base Backups mit Transaktionslogs und Point-in-Time Recovery; Storage-Systeme ermöglichten schnelle Snapshots; Deduplizierung und Objektstorage veränderten Übertragung und Retention.

Für laufende Windows-Anwendungen führte Microsoft VSS ein koordiniertes Modell aus Requester, Writer und Provider ein; die Technik erschien mit Windows XP beziehungsweise Windows Server 2003. In verteilten und containerisierten Plattformen wurden Snapshot- und Orchestrierungs-APIs standardisiert, ohne dadurch Anwendungskonsistenz automatisch zu lösen (Microsoft: Volume Shadow Copy Service, Kubernetes: Volume Snapshots).

Cyber-Recovery verschob den Schwerpunkt erneut. Versionierung und Offsite-Kopien genügen nicht, wenn hochprivilegierte Identitäten alle Ziele löschen können oder kompromittierte Images zurückkehren. Isolierte Recovery-Instanzen, getrennte Identitäten, unveränderbare Objektversionen, deklarative Infrastruktur und saubere Wiederanlaufzonen ergänzen klassische Voll-, inkrementelle und logbasierte Backups. Amazon S3 Object Lock wurde 2018 als WORM-Schutz für Objektversionen eingeführt; die Funktion illustriert diesen Übergang, ersetzt aber weiterhin weder Anwendungskonsistenz noch Restore-Tests (AWS: Einführung von S3 Object Lock, Amazon S3: Object Lock).

Admin-Checkliste

Die Planung ist erst belastbar, wenn Ziele, Kopien, Zugriffe und Tests gemeinsam dokumentiert sind. Die Checkliste fasst diese Abhängigkeiten für Review und Restoreübung zusammen.

• Geschäftsprozesse, MTD sowie RTO und RPO je Systemfunktion sind freigegeben.
• Alle führenden und abgeleiteten Zustände der Messaging-Plattform sind inventarisiert.
• Anwendungskonsistenz, Log-Kette und Konsistenzgruppen sind produktspezifisch dokumentiert.
• Queue-Restore, mögliche Duplikate und Wiederfreigabe von Ein- und Ausgang sind geregelt.
• Konfiguration, Policies, DNS, Zertifikate, Schlüssel, Secrets, Lizenzen und Runbooks sind im Scope.
• Mindestens eine Recovery-Kopie liegt getrennt von Produktion und primären Administrationskonten.
• Unveränderbarkeit, Isolation, Verschlüsselung und Schlüsselzugriff sind getrennt bewertet.
• Recovery-Control-Plane und Zielkapazität funktionieren ohne die kompromittierte Produktion.
• Wiederanlaufreihenfolge folgt einer gepflegten Abhängigkeitsgrafik.
• Tests stellen einen vollständigen Mail-Geschäftsvorgang wieder her und messen RPO/RTO.
• Ergebnisse, neue Abhängigkeiten und Abweichungen fliessen in Runbook und Architektur zurück.