40 GB Datenbank, 2 GB Grenze

1. Oktober 2026

Wer als Veeam Cloud & Service Provider einen Support-Fall mit der Service Provider Console hat, bekommt früher oder später diese Bitte: Laden Sie ein Backup der VSPC-Datenbank hoch. Klingt nach zwei Klicks. Bei einer Datenbank mit 40 GB und einem Upload-Portal, das große Dateien nicht mag, ist es das nicht.

Wir mussten das in den letzten Wochen öfter machen, als uns lieb war. Hier ist der Ablauf, der sich eingespielt hat, und der Stolperstein, über den fast jeder einmal fällt.

Die Kurzfassung zum Kopieren

# 1. Platz prüfen (Datenbankgröße x 1,4 sollte frei sein)
Get-PSDrive C | Select-Object @{L='FreeGB';E={[math]::Round($_.Free/1GB)}}

# 2. Natives SQL-Backup, online, ohne Dienst-Stopp
SqlCmd -E -S localhost -Q "BACKUP DATABASE [VSPC] TO DISK='C:\temp\VSPC-DB.bak' WITH STATS"

# 3. Zippen und in 1,5-GB-Teile schneiden (Compress-Archive scheitert über 2 GB)
& "C:\Program Files\7-Zip\7z.exe" a -tzip -v1500m "C:\temp\VSPC-DB.zip" "C:\temp\VSPC-DB.bak"

# 4. Teile hochladen, Empfang abwarten, dann aufräumen
Remove-Item C:\temp\VSPC-DB.bak -Force

Wer wissen will, warum das so aussieht, liest weiter.

Ausgangslage

Die VSPC speichert ihre Daten in Microsoft SQL Server. Bei uns liegt die Datenbank VSPC in einer eigenen Instanz auf einem separaten SQL-Server. Veeam will ein natives SQL-Full-Backup als .bak, keine kopierten Dateien und keinen VM-Snapshot. Das geht ohne Management Studio mit SqlCmd, das auf jedem SQL-Server ohnehin liegt.

Veeam beschreibt das Verfahren selbst in KB1471 , für SQL Server und PostgreSQL, für Backup & Replication, Enterprise Manager und die VSPC. Dort steht auch die Bitte, das Backup vor dem Hochladen zu zippen. Die meisten Datenbank-Backups schrumpfen dabei laut Veeam auf etwa 15 % ihrer Größe.

Alles Folgende läuft in einer PowerShell als Administrator auf dem SQL-Server. Vorher den freien Platz prüfen. Das .bak wird etwa so groß wie die Datenbank, die ZIP-Teile kommen dazu:

Get-PSDrive C | Select-Object @{L='FreeGB';E={[math]::Round($_.Free/1GB)}}

Faustregel: Datenbankgröße mal 1,4 sollte frei sein.

Schritt 1: das Backup

SqlCmd -E -S localhost -Q "BACKUP DATABASE [VSPC] TO DISK='C:\temp\VSPC-DB_2026-09-30.bak' WITH STATS"

-E meldet sich mit dem Windows-Konto an, WITH STATS zeigt den Fortschritt in Zehnerschritten. So sieht das aus:

10 percent processed.
20 percent processed.
[...]
100 percent processed.
Processed 5119992 pages for database 'VSPC', file 'VSPC' on file 1.
Processed 55600 pages for database 'VSPC', file 'VSPC02' on file 1.
Processed 4 pages for database 'VSPC', file 'VSPC_log' on file 1.
BACKUP DATABASE successfully processed 5175596 pages in 48.011 seconds (842.189 MB/sec).

Unsere 40 GB waren in 48 Sekunden durch.

Das Backup läuft online. Die VSPC muss dafür nicht gestoppt werden.

Zwei Anpassungen je nach Umgebung. Liegt die Datenbank in einer benannten Instanz, gehört die in den Server-Parameter, etwa -S localhost\MSSQLVSPC. Und wer den Datenbanknamen nicht sicher weiß, fragt vorher nach:

SqlCmd -E -S localhost -Q "SELECT name FROM sys.databases"

Schritt 2: zippen, und hier liegt die Falle

Naheliegend wäre das Bordmittel von PowerShell:

# So nicht bei großen Dateien:
Compress-Archive -Path C:\temp\VSPC-DB_2026-09-30.bak -DestinationPath C:\temp\VSPC-DB.zip

Das scheitert. Compress-Archive baut auf einer .NET-Schnittstelle auf, die laut Microsoft Dateien nur bis 2 GB verarbeitet. Bei einem .bak mit 40 GB gibt es eine Fehlermeldung, die mit dieser Grenze wenig zu tun zu haben scheint.

Der robuste Weg ist 7-Zip. Es kann gleich noch etwas, das wir ohnehin brauchen: das Archiv in Teile schneiden. Teile mit 1,5 GB laden entspannt hoch, und bricht eine Übertragung ab, wiederholt man nur diesen einen Teil:

& "C:\Program Files\7-Zip\7z.exe" a -tzip -v1500m "C:\temp\VSPC-DB_2026-09-30.zip" "C:\temp\VSPC-DB_2026-09-30.bak"

-v1500m erzeugt VSPC-DB_2026-09-30.zip.001, .002, .003 und so weiter. Alle Teile zusammen sind das Archiv. Die Ausgabe:

Scanning the drive:
1 file, 42399336960 bytes (40 GiB)

Creating archive: C:\temp\VSPC-DB_2026-09-30.zip

Add new data to archive: 1 file, 42399336960 bytes (40 GiB)

Files read from disk: 1
Archive size: 12891740444 bytes (13 GiB)
Volumes: 9
Everything is Ok

Aus 40 GiB wurden 13 GiB in neun Teilen, also knapp ein Drittel. Die 15 % aus der KB hat unsere Datenbank nicht geschafft, aber es sind immer noch 27 GiB weniger, die durch die Leitung müssen.

Schritt 3: dem Support sagen, was kommt

Zwei Zeilen im Fall ersparen eine Rückfrage und damit einen Tag:

Full VSPC database backup uploaded as split archive: VSPC-DB_2026-09-30.zip.001–.00X. Please join all parts before extracting; MS SQL native full .bak inside. State as of 30.09.2026, 08:00 local time.

Das „please join before extracting" steht da nicht zum Spaß. Wir hatten schon den Fall, dass jemand Teil .001 allein entpacken wollte.

Schritt 4: aufräumen

Das .bak hat nach dem Zippen seinen Dienst getan und belegt nur noch Platz auf dem Systemlaufwerk:

Remove-Item C:\temp\VSPC-DB_2026-09-30.bak -Force

Die ZIP-Teile behalten wir, bis der Support bestätigt, dass alles angekommen ist.

Wenn der Support den Stand von gestern braucht

Manchmal reicht der aktuelle Zustand nicht, etwa wenn ein Fehler mit dem Stand davor verglichen werden soll. Als Backup-Dienstleister sichern wir unsere SQL-Server selbst. Aus dem eigenen Veeam-Backup holen wir die Datenbankdateien eines beliebigen Tages per File-Level-Restore, hängen sie unter neuem Namen an die Instanz (CREATE DATABASE [VSPC_KOPIE] ... FOR ATTACH) und erzeugen aus dieser Kopie mit den Schritten oben ein .bak. Die produktive Datenbank bleibt unberührt. Schritt für Schritt steht das in Die Datenbank von gestern, ohne VBR .

Wie viel dieser Handgriff wert sein kann, steht in Das Backup-Unternehmen, das sich mit dem eigenen Backup rettete .