ScottPletcher, the idea is not to save space in the backup, but in the the restored database.

If you backup empty database (new database for example) of 2GB, then the backup will be about 6MB. This is not an issue to store 6MB without any shrink ;-). But once you restore the database, then it need to be restored to 2GB, and this is the issue. The restored file which is 2GB, can be shrink significant.

* Once again, This is not a solution for production, but simply a Fun play, as I mentioned in any opportunity 🙂

Perry Whittle, you are totally right regarding "get some extra space", but this is not fun and any DBA should know it :crazy: .

* Regarding "shrink the source db before backing up" or "remove or move objects to make space", these you should not do in production, only because on your home disk you don't have space to restore the production. These are actions you should do if they fit the production and without any consideration of one-time restore that you want to do in testing environment. If the testing environment do not fit, then you should upgrade it.

The case study for the article is that we might want one-time need to copy the production database to your testing laptop...

This is not something to do in production! But only for fun :crazy: in your "home" environment.