Restore backup fails - not enough disk space I have a backup that's about 6Gb. It's a "light" backup of the original (with the log tables purged), which is about 14Gb.

I try to restore the backup on my SQL Express local server. It fails with a message like : System.Data.SqlClient.Error: insufficient disk space. It asks for 227,891,019,776 bytes, which is absolutely crazy, and almost as big as my whole hard drive.

As found on other sites, I tried RESTORE FILELISTONLY FROM DISK = 'backupfile.bak'.

The data file (column Size) is 6,888,226,816 in size, but the log file is 221,006,987,264. The column BackupSizeInBytes returns 6,259,736,576 and 0.

So, if I understand correctly, restore checks that I have enough space to restore the "theorical" size of the log file before proceeding, disregarding the actual log file size ?

How can I bypass that ? It's a bit difficult to get a backup, so if I can resolve my problem without having to return on the production server, it would be great.

Thank you !

Oh BTW, I am on SQL Server 2008 R2 Express.
Note that the backup size does not include empty pages, but when you actually perform the restore, the data and log files will be over 200 GB, because it has to restore exactly what the source system had (including a 200+ GB log file, regardless of how full it was). 

If you don't want to risk data loss, you need to correct that at the source (e.g. shrink the log file to something reasonable), take another full backup, and restore that. I'm not sure I understand why it's difficult to get a backup - this is a pretty standard operation, and should be a service provided by anyone you're paying to host SQL Server.

You should also fix the source database to either (a) be in the right recovery model or (b) take log backups more frequently. Your log file is ludicrous because you are in full recovery and never take log backups. If you need point in time recovery, start backing up your log. If you don't, switch to simple. The log file should manage itself if you have it configured correctly. If you don't, then when it gets like this, shrinking should be a one-time operation, and then you should fix the configuration so you're not doing this again next week...