Point-in-Time-Recovery (PITR) ist die Fähigkeit einer Datenbank, ihren Zustand auf einen frei wählbaren Zeitpunkt in der Vergangenheit zurückzusetzen — nicht nur auf den letzten vollständigen Backup-Zeitpunkt. Ziel ist, einen fehlerhaften Zustand (versehentliches Löschen, fehlerhafte Massenbuchung, Datenkorruption) möglichst knapp vor dem Vorfall wiederherzustellen, ohne alle Stunden oder Tage danach zu verlieren.
Kontext
Für SAP Business One setzt PITR auf zwei Bausteinen auf: Einem Full Backup als Ausgangspunkt und fortlaufenden Log-Backups (Transaction Log bei MS SQL, Log-Segmente bei HANA), die seitdem alle Änderungen zeitlich lückenlos protokollieren. Beim Restore wird das Full Backup eingespielt und die Logs bis zum gewünschten Zeitstempel (z.B. 15:43:12 am 03.02.2026) nachgerollt. Je kleiner das Log-Backup-Intervall, desto präziser der wiederherstellbare Zeitpunkt — in B1-Produktivumgebungen sind 15–30 Minuten üblich. PITR wird typischerweise benötigt, wenn eine Massenaktion Daten beschädigt (z.B. fehlerhafter DTW-Import, falscher DATEV-Import, falsches Script) und ein sauberer Vor-Zustand gebraucht wird. Auf HANA muss die Log-Mode-Einstellung auf normal stehen (nicht overwrite), auf MS SQL muss das Recovery-Modell auf Full stehen — beides ist in produktiven B1-Installationen Standard.
Abgrenzung
PITR ist nicht identisch mit einem Snapshot: Snapshots frieren einen Zustand einmalig ein, PITR erlaubt kontinuierliches Rückrollen. Es ist auch nicht dasselbe wie Hochverfügbarkeit (HA) — HA hält den Betrieb bei Hardware-Ausfällen aufrecht, PITR repariert logische Fehler. Gegenüber einem stündlichen Full-Backup ist PITR deutlich effizienter, weil nur die Logs statt der kompletten Datenbank laufend gesichert werden müssen. Voraussetzung ist eine disziplinierte Backup-Strategie — ohne gesicherte Logs kein PITR.
ReAct und RLEF: Wie Künstliche Intelligenz aus echten Fehlern lernt — und was der automatische Bankabgleich in SAP Business One damit zu tun hat
SAP B1 10.0 FP2608: Service Layer KI als transaktionalen Schicht
Process Reward Models: Warum ein richtiges Ergebnis noch keinen richtigen Weg beweist
Test-Time Compute Scaling: Warum ein kleineres KI-Modell am Ende gewinnen kann — und was der Lieferantenvergleich in SAP Business One damit zu tun hat
RLHF und Reward-Modelle: KI-Hype oder was der Genehmigungsprozess in SAP Business One damit zu tun hat
