Video Screencast Help

Moving data from LTO-2 to LTO-4

Created: 11 Dec 2012 • Updated: 09 Feb 2013 | 12 comments
This issue has been solved. See solution.

Could anyone tell me if there's a simple way to move lots of data from LTO-2 to LTO-4 easily? We are getting rid of LTO-2s and I would like to transfer everything to LTO-4 or even LTO-5. I have about 500 LTO-2 tapes so doing this manually one by one would be a PITA...

thanks!

Discussion Filed Under:

Comments 12 CommentsJump to latest comment

C_Moisan's picture

Sorry, I should have mentionned that we are using NB 7.5.0.3

mph999's picture

Two choices, bupilcate all the images, or duplicate all the tapes - all tapes is probably easier.
A list of tapes containing images can be found from :
bpmedialist

You can then run a loop and feed the tape list into bpduplicate command

Eg.

cat media_list |while read TAPE
do
bpduplicate -id $TAPE -dstunit -dp
done

where 'media_list' is a file containing a list of the media ids.

Martin

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
SOLUTION
bills's picture

mph99:

I have often wondered whether the -id option to bpduplicate would do this - the man page is unclear on what it does with spanned images:

"Search the image catalog for backups to duplicate that are on this media ID. If the original is fragmented between different media IDs, NetBackup duplicates only the backups that exist on the specified media ID. Backups that span media are duplicated, but not any other backups on the spanned media ID."
 

The second sentence to me indicates that backup fragments on spanned media will NOT be duplicated.  But the third sentence seems to indicate that spanned fragments ARE duplicated.  Can you clarify?

To answer the orignal question, I would have said duplicate the images:

for tape in `cat media_list` ; do

  bpimmedia -mediaid $tape | awk '/IMAGE/ {print $4}' >> imagelist

done

bpduplicate -dstunit <stunit> -dp <pool> -Bidfile imagelist
 

If you do this, make a copy of the imagelist file, as bpduplicate will delete it, and it will take a while to generate it.

Bill

Andy Welburn's picture

"Search the image catalog for backups to duplicate that are on this media ID. If the original is fragmented between different media IDs, NetBackup duplicates only the backups that exist on the specified media ID. Backups that span media are duplicated, but not any other backups on the spanned media ID."

 

As I read it:

Media_ID "1" has images A and B on it. Image A is totally on "1", Image B spans to Media_ID "2"

Media_ID "2" has images B and C on it. Image B as the last 'fragment' from above, Image C in toto.

 

A bpduplicate of Media_ID "1" would duplicate images A & B only (altho' it would require Media_ID "2" to complete image B)

 

I *could* be (very) wrong as it's not overly clear ;)

C_Moisan's picture

Thanks for your answers, guys, I will look into this with my colleague who's better at this than me.

mph999's picture

Hi Guys,

 

My understanding is that if you have two tapes and one contains an image spanning onto the second tape, and the second tape contains other images :

Duplicating tape 1 will duplicate tape 1 + the image on tape 2

Duplicating tape 2 will duplicate the remaining images on tape 2

... so it should work fine.

In fact I just had a case like this, and a customer duplicated their tapes using this method I explained.

 

You could duplicate images as opposed to tapes, this is fine, but you'll probably end up with many more tape loads/ unloads - not a big deal, but I think going on tape would be easier to keep track of, for a start there are probably less tapes than the number of images ...

Martin

 

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
bills's picture

Andy and mph99 - if your interpretation is correct, you'll end up duplicating image B twice, unless bpduplicate only keys off of the initial fragment.

tape 1 contains all of image A and the first half of image B

tape 2 contains the second half of image B and all of image C

duplicating tape 1 would get all the images on tape 1 -  A and B - and would require tape 2

duplicating tape2 would get all the images on tape 2 - B and C - and would require tape 1

Maybe I'll actually have to test it....

Bill

mph999's picture

No, I think it will only dupliate images where the first fragment is on the tape - if further fragments are on other tapes it will go get them.

Martin

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
Andy Welburn's picture

No, I think it will only dupliate images where the first fragment is on the tape - if further fragments are on other tapes it will go get them.

^ That!

 

Your intention is to only duplicate images on 'tape 1' (i.e. A & B) - uses tapes 1 & 2

If your intention is to then duplicate images on 'tape 2' (i.e. C only) - only uses tape 2

 

"Maybe I'll actually have to test it...."

- that'll prove it conclusively!

bills's picture

It appears that bpduplicate will duplicate images multiple times if they span tapes using the -id flag (duplicate duplicates, if you will).

Here is some (heavily edited) proof.  First I list the contents of two media, only looking for copy 3.  Each backupid here has 3 copies, the 1st two of which are on disk.  The full listing is less pleasant to look at.  You'll have to take my word for the fact that each physical tape only has the listed fragments.

You can see there are spanned images - host1_1354984347 starts on LT0001, then continues on LT0002.  host2_1354970317 starts on LT0003 (not listed) then continues on LT0001.  host4_1354981606 starts on LT0004, goes on to LT0005, then LT0002, and finishes on LT0006 (only LT0002 is listed).

If I try to duplicate LT0001, bpduplicate wants to grab host2_1354970317, whose 1st fragment is on LT0003 - showing that it's going to get images that don't start on the specified media, which I suspected earlier.  Then it's going to grab host3_1354974745, which is wholly contained on LT0001, then it will get host1_1354984347, whose first fragment is on LT0001, then spans to LT0002 - which shows that it will get spanned images (which we all suspected).

If I try to duplicate LT0002, it again gets host1_1354984347, even though its first fragment is in LT0001 (and the entire image was duplicated when I did LT0001).  Then it gets host4_1354981606, whose fragments span 4 tapes, but only the 4th and 5th or on the specified media.

Let me know if you agree with my analysis....

 

Bill

$ bpimmedia -mediaid LT0001 | egrep "IMAGE|FRAG 3"
IMAGE host1 8 host1_1354984347
 FRAG 3 1 LT0001
 FRAG 3 2 LT0001
 FRAG 3 3 LT0002
IMAGE host2 8 host2_1354970317
 FRAG 3 1 LT0003
 FRAG 3 2 LT0001
IMAGE host3 8 host3_1354974745
 FRAG 3 1 LT0001

$ bpimmedia -mediaid LT0002 | egrep "IMAGE|FRAG 3"
IMAGE host1 8 host1_1354984347
 FRAG 3 1 LT0001
 FRAG 3 2 LT0001
 FRAG 3 3 LT0002
IMAGE host4 8 host4_1354981606
 FRAG 3 1 LT0004
 FRAG 3 2 LT0005
 FRAG 3 3 LT0005
 FRAG 3 4 LT0002
 FRAG 3 5 LT0002
 FRAG 3 6 LT0006

$ bpduplicate -p -id LT0001 -s 12/7/2012 -cn 3
INF - Skipping copy 1 of backup id host1_1354984347, is not required copy 3.

INF - Skipping copy 2 of backup id host1_1354984347, is not required copy 3.

INF - Skipping copy 1 of backup id host2_1354970317, is not required copy 3.

INF - Skipping copy 2 of backup id host2_1354970317, is not required copy 3.

INF - Skipping copy 1 of backup id host3_1354974745, is not required copy 3.

INF - Skipping copy 2 of backup id host3_1354974745, is not required copy 3.

 Media id = LT0003  Server = host5
 Bid = host2_1354970317  Kbytes = 247849728  Filenum = 48  Fragment = 1

 Media id = LT0001  Server = host5
 Bid = host2_1354970317  Kbytes = 474169419  Filenum = 1  Fragment = 2
 Bid = host3_1354974745  Kbytes = 57230457  Filenum = 2  Fragment = 1
 Bid = host1_1354984347  Kbytes = 1048575232  Filenum = 3  Fragment = 1
 Bid = host1_1354984347  Kbytes = 96023808  Filenum = 4  Fragment = 2

 Media id = LT0002  Server = host5
 Bid = host1_1354984347  Kbytes = 429724192  Filenum = 1  Fragment = 3

$ bpduplicate -p -id LT0002 -s 12/7/2012 -cn 3
INF - Skipping copy 1 of backup id host1_1354984347, is not required copy 3.

INF - Skipping copy 2 of backup id host1_1354984347, is not required copy 3.

INF - Skipping copy 1 of backup id host4_1354981606, is not required copy 3.

INF - Skipping copy 2 of backup id host4_1354981606, is not required copy 3.

 Media id = LT0001  Server = host5
 Bid = host1_1354984347  Kbytes = 1048575232  Filenum = 3  Fragment = 1
 Bid = host1_1354984347  Kbytes = 96023808  Filenum = 4  Fragment = 2

 Media id = LT0002  Server = host5
 Bid = host1_1354984347  Kbytes = 429724192  Filenum = 1  Fragment = 3
 Bid = host4_1354981606  Kbytes = 1048575232  Filenum = 2  Fragment = 4
 Bid = host4_1354981606  Kbytes = 295219712  Filenum = 3  Fragment = 5

 Media id = LT0006  Server = host1
 Bid = host4_1354981606  Kbytes = 660275744  Filenum = 3  Fragment = 6

 Media id = LT0004  Server = host1
 Bid = host4_1354981606  Kbytes = 468236032  Filenum = 5  Fragment = 1

 Media id = LT0005  Server = host1
 Bid = host4_1354981606  Kbytes = 1048575232  Filenum = 3  Fragment = 2
 Bid = host4_1354981606  Kbytes = 697864448  Filenum = 4  Fragment = 3

mph999's picture

Hmm, interesting, I can't disagree with what you have showed.

However, I wonder if it were able to actually start the copies, would it then drop the images that start on different media - that is, does it make a chack a bit 'later on' that we didn't see on this test.

Just an idea ...

I'll have a play at some point.

No matter, looks like the better way may be to duplicate the OP tapes by image, at least we can be 100% sure that each will only be duplicated once.

Martin

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
bills's picture

I just tried running the duplicate of LT0002, which should  not have done anything, since no images start on that media (given earlier assumptions).  It reserved all the media listed, and was in the process of mounting a media other that the one specified on the command line.

I'll consider this definitive.....

 

Bill