Third Party Backups of Databases and White Space
-
I was getting rid of some of the inactive user accounts on our Exchange 2010 server tonight and was reading that even though you delete the mailbox(es), the database itself never decreases in size on disk. It merely has whitespace that can be reused for new mailboxes. You can shrink the database size on disk with an offline defragmentation if needed. I equate that to shrinking a SQL database / the log files.
Now, if the database size on disk (in this case it was Exchange) does not shrink without an offline defragmentation, what happens during a backup? Since software like Veeam uses CBT, will the space freed up by removing old mailboxes translate to a decrease in the size of backups? If, for example, I trimmed the Exchange database size by 20 GB, will a full backup of that VM with Veeam be 20 GB smaller? Part of me thinks it should be, but I am not sure it will be since the space on disk did not change.
And let's take that into the SQL realm as well. If there is whitespace, will a SQL backup's size include the size of the whitespace?
I'm trying to wrap my head around this a bit better. Any help is much appreciated.
-
@NetworkNerd said:
You can shrink the database size on disk with an offline defragmentation if needed. I equate that to shrinking a SQL database.
It's not similar. That's actually what it is. Exchange runs on a relational database under the hood and shrinking that is what reclaims the space.
-
@NetworkNerd said:
Now, if the database size on disk (in this case it was Exchange) does not shrink without an offline defragmentation, what happens during a backup? Since software like Veeam uses CBT, will the space freed up by removing old mailboxes translate to a decrease in the size of backups? If, for example, I trimmed the Exchange database size by 20 GB, will a full backup of that VM with Veeam be 20 GB smaller? Part of me thinks it should be, but I am not sure it will be since the space on disk did not change.
Depends, if they are backing up the database via the database itself that free space is unknown to the backup utility because it is getting the data out of the database, not an image of the "filesystem." But if you simply image the filesystem, then you get the whitespace. So it all depends on approach.
Let's take MySQL as an example. Use MySQL itself to dump its own database and no whitespace will come through as defragmentation doesn't apply to a data transfer (no different than normal filesystem fragmentation.) But if you take an image of the files used by the database then the whitespace (the fragmentaion) is present and you are grabbing it.
-
A database file on disk is basically like a VHD, it's a single file holding a virtual filesystem. So let's step back and think about this just like a filesystem.
Let's assume that you have a heavily fragmented filesystem. If you back that up as an image (say from ESXi) you will image all of the fragmention because you are grabbing the entire filesystem, fragmentation and all. But if you back up individual files, of course there is no fragmentation so you only get the size of the files themselves. It seems obvious when talking about files that fragmentation exists "between" the files, not inside of them. An individual file does not increase in size nor does the number of files increase with fragmentation - only the bloat in the filesystem itself does.
Hopefully that answers the question.
-
Good read, thanks.
