cancel
Showing results for 
Search instead for 
Did you mean: 

Tape Duplication - Is Compression Enabled By Default

joe1871
Level 3

I had a backup job that actually spanned three tapes - it has at least 3 TB or more data that it is running a full NDMP backup on.  This is from a NetApp filer, via NDMP, and to Ultrium 5 tapes.  The original backup uses no compression.  The backup job took 27 hrs.  THis is using one Master/Media server and one Dell Powervault TL4000 dual head library.  The NBU server is running NBU version 7.5.0.5.

This is the first time I have ever run a duplication job.  I used a Catalog based duplication.  I was prepared for the job to basically take something less than the 27 hours the original backup took.  It ended up being 6 hours and change.  I also expected it to need three tapes, it used one.  I am concerned that something is rotten in Denmark, this is to good to be true .  Does this make sense?  Is compression automatically enabled on the duplication job?  How did it fit on 1 tape without c ompression?

Let me know if you have any insight into theis.  I am scratching my head and really wondering what is on that one tape.  I will obviously run some kind of inventory report on it.

Last question - is there any way to tie out the Job ID you get in the Activity Monitor to the Backup ID you get in the reports?  Is there a report that lists both?  None of the canned reports that you get from the Activity screen have both values.  I ran a couple of reports and exported them into Excel and did some Excel magic to get the desired result, but there must be a report.

Thanks in adhvance.  I appreicate any help you provide!

Joe

1 ACCEPTED SOLUTION

Accepted Solutions

mph999
Level 6
Employee Accredited

The drives use hardware compression by default, for example, if on Solaris the path was /dev/rmt/0cbn to the drive, the 'c' bit of 'cbn' means compress.

So the tape driver / tape drive hardware handles compression.

I would run a verify on each copy, make sure they check out.

At the moment, I can't explain the difference, but have seen similar on a multiple in-line copy where one copy used x tapes and the other used x+1 tapes, exactly the same data being sent to each drive at 'almost' exactly the same time.

Both copies were readable, issue was a fault with the tape drive, one of them wasn't compressing.

 

View solution in original post

5 REPLIES 5

mph999
Level 6
Employee Accredited

The drives use hardware compression by default, for example, if on Solaris the path was /dev/rmt/0cbn to the drive, the 'c' bit of 'cbn' means compress.

So the tape driver / tape drive hardware handles compression.

I would run a verify on each copy, make sure they check out.

At the moment, I can't explain the difference, but have seen similar on a multiple in-line copy where one copy used x tapes and the other used x+1 tapes, exactly the same data being sent to each drive at 'almost' exactly the same time.

Both copies were readable, issue was a fault with the tape drive, one of them wasn't compressing.

 

mph999
Level 6
Employee Accredited

Job ID you get in the Activity Monitor to the Backup ID 

Hmm, maybe opscenter has something (not looked so cannot give an answer).

You would find it I think in the trylogs:

/usr/openv/netbackup/db/jobs/trylogs (master) and could get it also from bptm log (media) but this doesn't qualify as a report.

jim_dalton
Level 6

I dont see theres any issue if what you say is true Joe: if you know for a fact that the original backup was not compressed and the duplciate was then its entirely believable. Personally I'd be adressing why the original wasnt compressed as it is unusual. The time to duplicate is no concern: its tape to tape not filer to tape, and the bottleneck in NDMP backups is almost always NDMP unless you are dealing with large files. What speed did the original 3 -tape job run at? Jim

RonCaplinger
Level 6

There are two types of compression available: hardware compression on the tape drives, and software compression available within NetBackup. 

You stated "The original backup uses no compression."; do you mean you know for a fact that hardware compression was turned off?  Or just that you did not check the box in the backup policy to compress the backup data using NetBackup's compression?

It sounds like your backup didn't compress the data with either hardware or software, but the duplication did allow hardware compression.  Without comparing the size of the backup data with the size of data on the tape, I can't be 100% sure, but I don't think you have a problem with the duplicated copy on tape.

From my experience, modern LTO hardware compression has no effect on backup performance, but software compression might.  There's a benefit of using one or the other, but not both at the same time.  I can't immediately think of a reason not to use hardware compression.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
My 2c: A hardware engineer once told me that hardware compression is enabled by default, but if data transfer is slow during backup, compression will be turned off in attempt to keep drive streaming and prevent shoe-shining. So, it is quite possible in your case that this is what happened. During duplication, the read from tape and write to other tape was done at good enough speed to keep compression turned on.