As Paul Randall stated in his MCM Internals on Backup/Restore for SQL Server, the backup file does not require the empty space in the database to be in the backup, but it DOES require it when restoring the backup. The backup file basically puts pointers to where the empty space needs to repopulate when it rebuilds it during the restore process.
Database compression works differently than removing empty space from backups. It uses something closer to a winzip algorithm. If you were to winzip/winrar/7zip with maximum compression your backup, you would get very similar space usage as SQL Server native compression. One of the benefits of using it native in SQL Server is it requires a lot less space to write to disk thus it's faster assuming your CPU isn't pegged.
Mr. Denny is also correct, so that could be part of it hence why I voted it back up.
Paul Randal's MCM video list including backup/recovery as mentioned:
After re-reading your answer there's some discrepancies I want to clarify, but the information stated above is still relevant.
You have a database that when you right click on the DB, properties, and space used, you see:
Free Space: 300MB
SP_HELPDB shows: 216GB
dbcc sqlperf('logspace'). What do you get back for the log life related to this DB? Please post your findings.
Please validate and get back to us.
10/29/2012 Edit after posting findings & using block comment code to drive Buck Woody crazy:
Next, please run this, it will tell us everything about your backup right when SQL Server took it. This modified script originally from Pinal will help us validate if something after the backup happened to the file, or if SQL Server really just spit out a small backup:
SELECT TOP 100
CAST(CAST(s.compressed_backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS CompBkSize,
CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,
s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,
CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,
CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,
WHEN 'D' THEN 'Full'
WHEN 'I' THEN 'Differential'
WHEN 'L' THEN 'Transaction Log'
END AS BackupType,
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
ORDER BY s.backup_start_date DESC, s.backup_finish_date
Edit after final results were posted:
As suspected, your backups have compression enabled. As you can see in the query, Compressed backup size shows 38GB where as just 'backup size' shows 228GB. Review your backup scripts, you will find 'WITH COMPRESSION' in it.
Remember the factors that affect backup size:
-Transaction Log files are backed up along the SQL Server backup file. This is for redo/undo operations during the recovery portion.
-Data pages, GAM, SGAM, etc. are to the backup file. Empty space in the database is removed and only pointers are placed, thus if you have lots of free space your backup will remain small. However it will be required when you restore.
-Compression plays a huge factory typically in SQL Server databases. One of the biggest contributing factors.
-Breaking up a backup file into smaller multiple files obviously will also affect size.
Let us know if you have any questions but your original question regarding the small backup size is resolved.