Backup file HUGE compared to DB size

Question

Backup file HUGE compared to DB size

Anthony Fourie

Old Hand

Points: 347
More actions
November 15, 2012 at 8:12 am

#266970

Hi Guys,
Have a strange one...
Found a job running on one of my servers. Job did a full backup of a database, using the following:
BACKUP DATABASE [tinyDB]
TO DISK = N'<backup drive location here>'
WITH NOFORMAT
, INIT
, SKIP
, NOREWIND
, COPY_ONLY
, NOUNLOAD
, STATS = 10
All fine and dandy that the guy decided to set up a backup for this DB, but what scares me is the size of the backup compared to
the size of the DB and LOG. Backup ends up at 250+GB, but when I do a normal backup of the database I end up with a 3GB backup file.
How the heck :crazy:... How is that possible?? Can you guys please help me out with any experiences that you guys have had
in a similar situation??
Grateful for all replies..
Anthony
/Ants

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Scott D. Jacobson SSCertifiable Points: 6149 More actions · Answer 1

My first thought was that the process was appending backups. However, INIT and SKIP options imply that it should be overwriting any old backups.

What happens if you try to restore the very large file? Do you see multiple backups in there?

Ant-Green SSC Guru Points: 113507 More actions · Answer 2

whats the output of RESTORE HEADERONLY 'backup path.bak'?

Scott D. Jacobson SSCertifiable Points: 6149 More actions · Answer 3

anthony.green (11/15/2012)
whats the output of RESTORE HEADERONLY 'backup path.bak'?

Good one Tony. I forgot about RESTORE HEADERONLY.

Anthony Fourie Old Hand Points: 347 More actions · Answer 4

Hi Guys,

Thanks for the replies, unfortunately a team member went and deleted the file due to disk space constraints...

Though I would love to know if I used the RESTORE HEADERONLY/RESTORE and found that there were multiple files,

why would it do that if INIT and SKIP were specified??

Like I say this was so strange, and I have no idea would could be happening...

Any ideas to what you think could have happened??

Thanks,

Anthony

/Ants

Scott D. Jacobson SSCertifiable Points: 6149 More actions · Answer 5

Just out of curiosity, was the Agent job running the TSQL commands you specified directly? Or was it executing a backup task via a Maintenance Plan? I've recently seen perfectly fine Maintenance Plan tasks start exhibiting odd, unintended behavior. Deleting and re-creating the Maintenance Plan task fixed the issue. I've learned through that experience that it's better to executing the backup action through the job directly or, even better, create some DBA stored procedures and then execute the sproc through a job.

Bhuvnesh SSC Guru Points: 59351 More actions · Answer 6

Scott D. Jacobson (11/16/2012)
I've learned through that experience that it's better to executing the backup action through the job directly or, even better, create some DBA stored procedures and then execute the sproc through a job.

+1

-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)

Anthony Fourie Old Hand Points: 347 More actions · Answer 7

Hi Scott,

Thanks for the reply... The script was executed directly "as is" by the SQL Agent as a job.

That's what is bugging me...

/Ants