I don’t understand why I am getting a Disk Space error.
Using 12.4.4 Professional. Backing up a MS SQL local database.
My .bak file is 375GB. I am using the Compress backup feature with no compression, .zip archive format, splitting the backup into 50GB files for more reliable upload to cloud storage. I end up with 7 files totaling 327GB. My temp folder is on a 1TB drive with nothing else stored on that drive, so the drive is empty with no backup running.
Why am I getting the disk space error? It should only be using up 702GB, correct?
9/15/2026 1:59:29 PM [Error] Failed to backup “DataBaseName” database with “Full” backup type: Xceed archiver error. > An unexpected internal failure occurred in the FileSystem component, or one of its descendants.
Type: Xceed.Zip.ZipArchive
FullName: \ > There is not enough space on the disk.
You mentioned that the .bak file is 375 GB, but after creating a ZIP archive, you get 7 files totaling only 327 GB. Normally, with compression, the archive should not be much smaller than the original .bak file.
What is the actual size of the .bak file before it is archived?
As another option, you could enable SQL Server backup compression in the backup options. This would reduce the size of the .bak file itself and also reduce the temporary disk space required.
This is no longer an issue. I added another 512GB to the drive and it has not been a problem since.
I assume that what is actually happening is it is making the backup, and then creating a second copy from which it then creates the split files, so we essentially end up with 3 copies at once.
To answer the question, yesterday’s backup shows the .BAK file to be 376.024GB. The job history pane shows 328.39GB. The Compression/Split step in the backup process takes from 4:30am to about 2:00pm, so it appears that some compression is taking place. I’m not sure where that is coming from as the Compress Backups config is set to “.zip” and “None”. The SQL Server backup compression setting is set to “Default” (Off).
Thank you for the update and for sharing the additional details.
For a backup of this size, I would recommend trying a slightly different configuration: disable the ZIP compression step and enable native SQL Server backup compression instead.
Native SQL Server compression should be significantly faster than creating and processing such a large ZIP archive and should also reduce the temporary disk space required.
Unless minimizing the final archive size is particularly important for you, I think this would be a better configuration for a 375+ GB database.
My main reason for using the zip function is to split the database into smaller chunks as that seems to work better when we upload the backup to cloud storage.
Is it possible to do that with the SQL Compression?
Since you need to split your backups for cloud uploads, I’d recommend keeping your current ZIP configuration.
There’s no real benefit to enabling SQL Server compression as well, since the ZIP step already compresses the backup. Using both compression methods would only add unnecessary processing.
