cancel
Showing results for 
Search instead for 
Did you mean: 

SQL Backup - Byte count much more less than restore size

Alex_Zn
Level 6
Partner Accredited

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Alex_Zn
Level 6
Partner Accredited
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.

View solution in original post

6 REPLIES 6

CraigV
Moderator
Moderator
Partner    VIP    Accredited

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?page=content&id=TECH129694

Thanks!

Alex_Zn
Level 6
Partner Accredited
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.

CraigV
Moderator
Moderator
Partner    VIP    Accredited

...just what I posted wink

Alex_Zn
Level 6
Partner Accredited

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
Moderator
Moderator
Partner    VIP    Accredited

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

Alex_Zn
Level 6
Partner Accredited

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"