Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SQL Backup - Byte count much more less than restore size

Created: 07 Feb 2013 • Updated: 07 Feb 2013 | 6 comments
Alex Zn's picture
This issue has been solved. See solution.

When i perform backup using SQL Agent, i see "Byte count" (from job history -> Set Detail Information)  which is equal to 10 GB, but  actual size of databases is 85 GB. Also, i see 85 GB when i luch restore job and open selections. I use SQL 2005, so there is no compression. Backup goes to deduplication folder (no client side deduplication). Actualy i need to understand actual size of transfered data, to properly calculate backup window, i do not see it in Job Logs.

Comments 6 CommentsJump to latest comment

CraigV's picture

Hi Alex,

Read up on what a dedupe backup does. If they byte count on the dedupe folder is 10GB and you can restore the whole SQL DB, then dedupe is editing out everything it should...

Read up on it below:

http://www.symantec.com/business/support/index?pag...

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Alex Zn's picture

Ok. So I found out where devil is. "Byte Count" field shows real transferred size from client, but information in selections, shows real database size. In case of SQL database may fill more capacity than data of this database, because fields in SQL tables do not always filled completely with data, but size for this fields will be reserved. So when you will perform restore, only "Byte Count" will be restored, but finally database on client will use space which shown in selections.

SOLUTION
CraigV's picture

...just what I posted wink

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Alex Zn's picture

Sorry CraigV, your advises very helpful form me, but not at this time, cause you wrote about Deduplication influence, but in this case no matter are you using deduplication or store your backup on tape, case in tips with storing SQL data. Good luck!

CraigV's picture

What you just said above makes no sense...you mentioned dedupe...if your backup size is smaller then dedupe is working, and I don't know what tape has to do with this but OK. Glad it is sorted out. yes

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Alex Zn's picture

What you just said above makes no sense...you mentioned dedupe...

Ok i will try to clarify. I mentioned dedup, cause i did not know is there any influence of deduplication, it was only for more complete view of my environment.

...if your backup size is smaller then dedupe is working

Byte count show data which was transferred from client to backup server, so no difference if you using deduplication or not, size will be the same, only exception is client side deduplication in such case you will see only uniq data which was transfered from client. Backup size less than actual database size not cause i am using deduplication, it less cause SQL stores only data, and data less than tablespaces+data+indexes+something else.

and I don't know what tape has to do with this but OK

Sorry that i have confused you with not very good analogy, i just wanted to show that in any case whatever backup storage you use dedup or any else, Byte Count will be the same. Difference will be in "Stored Size"