Die Datenbank von gestern, ohne VBR

1. Oktober 2026

Der Veeam Agent für Windows wird unterschätzt. Er sichert einen alleinstehenden SQL-Server anwendungskonsistent und kann die Transaktionslogs gleich mitsichern. Dann kommt der Moment, in dem man die Datenbank mit dem Stand von vorgestern braucht, als Kopie neben der Produktion.

Und man stellt fest: Die bequemen Werkzeuge dafür, der Veeam Explorer for Microsoft SQL Server und das Einspielen der Logs bis zu einem beliebigen Zeitpunkt, gibt es laut Veeam nur zusammen mit Veeam Backup & Replication. Der Agent allein hat die Logs gesichert, einspielen kann man sie ohne VBR nicht.

Für den häufigsten Fall braucht man das auch nicht. Wenn der Stand eines Wiederherstellungspunkts reicht, führt ein einfacher Weg zum Ziel: die Datenbankdateien per File-Level-Restore holen und als Kopie anhängen. Kein VBR, kein Explorer, keine Unterbrechung der Produktion. Wir haben genau das kürzlich in einem Herstellerfall gebraucht, und es hat den Fall gedreht .

Wann der Weg reicht und wann nicht

Er reicht, wenn der Datenstand zum Zeitpunkt eines Backups genügt. Für Forensik, für einen Vergleich vorher und nachher, um gelöschte Datensätze aus einer Kopie zu holen, oder um einem Hersteller einen definierten alten Stand zu liefern. Bei Sicherungen alle ein bis vier Stunden ist das Raster fast immer fein genug. In unserem Fall lag der passende Punkt 72 Minuten vor dem Ereignis.

Er reicht nicht, wenn es sekundengenau zwischen zwei Backups sein muss, oder wenn die Produktivdatenbank selbst zurückgerollt werden soll. Dann führt der Weg über VBR mit dem Veeam Explorer oder über die Log-Backups von SQL Server selbst.

Schritt 0: Wo liegen die Dateien?

Bevor man im Backup sucht, fragt man die laufende Instanz. Das zeigt auch, wie viele Dateien die Datenbank hat, und das sind oft mehr als zwei:

SqlCmd -E -S localhost -Q "SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID('MeineDB')"

Typisch sind eine .mdf mit den Daten, eventuell weitere Datendateien und eine .ldf für das Transaktionslog. Die Endung .ndf für weitere Datendateien ist übrigens nur eine Konvention. Es kann auch eine zweite .mdf sein. Alle Dateien notieren, beim Anhängen müssen sie vollständig sein.

Schritt 1: File-Level-Restore

Im Veeam Agent, oder in der VBR-Konsole, wenn der Agent-Job dort verwaltet wird: Restore, dann File Level Restore, dann den Wiederherstellungspunkt wählen. Das Backup wird als Laufwerk eingehängt, und man navigiert zu den Pfaden aus Schritt 0.

Die Dateien in einen neuen, eigenen Ordner kopieren, niemals über die laufenden:

C:\SQL\RESTORE-KOPIE\MeineDB.mdf
C:\SQL\RESTORE-KOPIE\MeineDB02.ndf
C:\SQL\RESTORE-KOPIE\MeineDB_log.ldf

Vorher den Platz prüfen. Die Kopie braucht so viel wie die Datenbank. Soll später noch ein .bak daraus werden, kommt fast dasselbe noch einmal dazu. Faustregel: Datenbankgröße mal 2,2 frei halten.

Ein Hinweis, der gern verwirrt: Das Änderungsdatum der kopierten Dateien kann älter aussehen als der Wiederherstellungspunkt. Entscheidend ist der Zeitpunkt des gewählten Punkts, nicht das Datum an der Datei.

Schritt 2: als Kopie anhängen

Jetzt der eigentliche Handgriff. Die Dateien werden unter einem neuen Namen an dieselbe oder eine andere Instanz angehängt. Die Produktion läuft daneben unberührt weiter:

SqlCmd -E -S localhost -Q "CREATE DATABASE [MeineDB_KOPIE] ON (FILENAME='C:\SQL\RESTORE-KOPIE\MeineDB.mdf'), (FILENAME='C:\SQL\RESTORE-KOPIE\MeineDB02.ndf'), (FILENAME='C:\SQL\RESTORE-KOPIE\MeineDB_log.ldf') FOR ATTACH"

Dann kurz prüfen, ob sie lebt:

SqlCmd -E -S localhost -Q "SELECT state_desc FROM sys.databases WHERE name='MeineDB_KOPIE'"
# Erwartung: ONLINE

Das klappt, weil der Agent-Job mit anwendungskonsistenter Verarbeitung läuft. Die Dateien im Backup sind dann in sich stimmig, und bei uns lief das Anhängen jedes Mal im ersten Anlauf.

Ohne diese Einstellung ist das Backup nur crash-konsistent, und dann kann das Anhängen scheitern. Auf FOR ATTACH_REBUILD_LOG sollte man sich in dem Fall nicht verlassen: Das baut zwar ein neues Log auf, setzt aber laut Microsoft eine sauber heruntergefahrene Datenbank voraus. Genau die hat man bei einer crash-konsistenten Kopie nicht. Anwendungskonsistente Verarbeitung ist bei SQL-Servern deshalb keine Option, sondern Pflicht.

Schritt 3: ernten

Ab jetzt ist MeineDB_KOPIE eine ganz normale Datenbank:

Lesend vergleichen, Abfragen gegen Kopie und Produktion nebeneinander: [MeineDB_KOPIE].[dbo].[Tabelle] gegen [MeineDB].[dbo].[Tabelle].
Einzelne Datensätze zurückholen, per INSERT ... SELECT aus der Kopie in die Produktion. Mit Bedacht.
Ein .bak für den Support erzeugen, der Fall, der uns zu diesem Weg gebracht hat:

SqlCmd -E -S localhost -Q "BACKUP DATABASE [MeineDB_KOPIE] TO DISK='C:\temp\MeineDB_Stand-2026-09-02.bak' WITH STATS"

Wie man das .bak danach in hochladbare Teile zerlegt, und warum Compress-Archive dabei scheitert, steht in 40 GB Datenbank, 2 GB Grenze .

Schritt 4: aufräumen

Wenn die Kopie ihren Zweck erfüllt hat:

SqlCmd -E -S localhost -Q "EXEC sp_detach_db 'MeineDB_KOPIE'"
Remove-Item C:\SQL\RESTORE-KOPIE\* -Force

Solange ein Fall offen ist, lassen wir die Kopie angehängt. Vor allem dann, wenn der Wiederherstellungspunkt bald aus der Aufbewahrung fällt: Die extrahierte Kopie überlebt die Aufbewahrungsfrist, der Punkt im Backup nicht.

Was bleibt

Der Agent ist kein VBR. Für „gib mir den Stand von gestern als Kopie" muss er das auch nicht sein. File-Level-Restore, Dateien kopieren, FOR ATTACH, das ist alles. Die einzige echte Voraussetzung sollte längst erfüllt sein: anwendungskonsistente Verarbeitung im Agent-Job und ein Sicherungsraster, das zu den Fragen passt, die später gestellt werden.