best way to transfer NBU directories

[manatee]

in a few days, i'm getting a bigger (hooray!) hd for my backup images.

in the current setup, i have "/NBU" xfs filesystem where catalogs and backup images go (i presume coz that partition goes smaller when there are backups running). the size is 9TB and the new hd i'll be receiving is 15TB. my plan is there's no need to reinstall everything as long as i keep the same directory structure so i will just tar the whole "/NBU" and untar it to the new hd. viola!

comments?

[RiaanBadenhorst]

When you say catalogs, do you mean catalog backups?

Why not just keep both disks? Then you've got 24 :)

[manatee]

LOL i wished! 24TB?

well i assumed coz when i look at the contents of "databases/catalog/2" i see my clients folder there. and there is that "data" folder that contains .bin and .bhd files there.

[RiaanBadenhorst]

OK that is the dedupe catalog. I would just mirror the volume, its the least risk and least downtime.

[Marianne]

I am worried about this statement:

"...in the current setup, i have "/NBU" xfs filesystem where catalogs and backup images go "

I am sincerely hoping that these are MSDP catalogs and images ONLY as explained in my reply to your other post.
The entire mount point needs to be considered as a complete MSDP entity.

[manatee]

exactly! as there's no installation documentation done i'm not sure where things are. that's why i plan to just "mirror" the existing partition to the new one.

[manatee]

really hard to find where things are. so i did the next logical step and searched for the biggest directories (in the filesystem that always suffers from hd space whenever there are delayed duplications).

i found that in "/NBU_DSU1/data" there are multiple numerical directories there that are GBs in sizes (totalling 7.1TB). there are also journal directories. the files in the numerical directories end in .bin and .bhd so i'm guessing this are the backup images.

what i'll do before the next backup starts is to create a symlink pointing "/NBU_DSU1/data" to the new hd.

but the next question is, how will the duplication find out about the still pending backup images in the old hd?

[Marianne]

You have 2 choices:

1. mirror the volume to the new HD, break mirror when syncronized and remove old HD
2. STOP NBU,
   mount the new HD to a temp dir, use tar with cvf ... | ... xvf... to transfer the entire NBU mount point to the new mount point, verify source and destination contents is the same, unmount both, then mount the new HD to /NBU, then start NBU.

DO NOT create a sym link. I doubt that it is supported plus it WILL leave the old data orphaned.

You should never try to split the Dedupe volume across different mount points. You will end up breaking everything.

[manatee]

i don't get step 1 if there is a step 2 making it redundant.

isn't mirroring a volume like copying the contents?

anyway, my other issue is the vendor didn't create any LVM so i if i'm going to do some sort of mirroring, i'll have to do it from software. the destination filesystem thin-provisioned so i can expand later.

[GeForce123]

Marianne said you had 2 choices, not 2 steps to solve the issue of moving your data to the new HD.

[manatee]

@Marianne

my bad. didn't see that.

i guess this tells me to do the migration next week.

[Marianne]

I have edited my previous post. Important that NBU is stopped when you use any method other than mirroring.

I am curious to know how the dedupe location seems to be a separate mount point under / without being an independent volume?

[manatee]

finally found why i can't expand my current filesystem. previous vendor really didn't use LVM. it was under the control of the multipath daemon and most probably they booted into single user mode and did the partition and formatting there.

anyway, i have my new 14TB (what's left after partition and format) in multipath. used LVM this time so that i can expand it in the future.

i'm thinking, instead of copying everything from the old partition to the new, why i just not add this new partition as a new storage unit? but it begs the question, if i add a new storage unit, how can i tell NBU to store all new backup images, catalog images, etc to that new storage unit?

and also, how to tell NBU to keep using the old storage unit while the backup images there have not yet been duplicated?

below is the only place where i found how /NBU_DSU1 is being used. i guess the "dbpath" will be used as $dbpath/data to tell NBU where to store and find backup images (where .bin and .bhd files reside).

[manatee]

---

...

i'm thinking, instead of copying everything from the old partition to the new, why i just not add this new partition as a new storage unit? but it begs the question, if i add a new storage unit, how can i tell NBU to store all new backup images, catalog images, etc to that new storage unit?

and also, how to tell NBU to keep using the old storage unit while the backup images there have not yet been duplicated?

 ...

---

found half of the answers i'm looking for.

how to relocate the catalog images

how to relocate the EMM database

but i don't think i need to relocate the EMM database.

still looking how to relocate the backup images themselves tell NBU to start using that new location.

[Marianne]

Forget about those since you actually want to relocate MSDP on /NBU_DSU1. 

You cannot add a new (or another) MSDP location with existing MSDP in place - there can only be one. Unless you want to keep existing and add another mountpoint to expand MSDP.
I agree that you should get rid of /NBU_DSU1 since it seems to occupy the same physical disk (just another partition) as the OS and explains the poor performance of your MSDP. 

I have given you 2 options :

1. Mirroring (seems to be a no-go here)
2. Using tar with NBU down to move the entire contents of /NBU_DSU1
   rsync COULD be an 3rd option, using it with everything online, and then a final incremental rsync with NBU down - no guarantees from my side.

There may be other (lengthy) options:

1. Add the new volume to a new mount point and configure as Advanced Disk.  
   Change SLPs to use the AdvDisk for backup and dup to tape. Expire after Dup will be best.
   Allow existing MSDP to empty out (expire), then remove MSDP from config.
   I am not entirely sure that more than one AdvDisk can be used (you can lookup in Admin Guide or online). If so, carry on with next step:
   Add /NBU_DSU1 as Adv Disk and change SLPs to use this for backup. Expire after Dup.  (keep an eye on disk usage)
   Allow AdvDisk on new volume to empty out (expire).
   Remove new volume AdvDisk from config.
   Create folders on new volume mount point as per Dedupe Guide, then config as MSDP.
   Change SLPs
   Remove /NBU_DSU1 
2. Start backing up directly to tape (look at multiplexing and multistreaming to ensure good performance).
   Allow existing MSDP on /NBU_DSU1 to empty out (expire), then remove MSDP from config.
   Config new volume as MSDP. 

I honestly cannot see any other way. 

[manatee]

---

@Marianne wrote:
...

There may be other (lengthy) options:

1. Add the new volume to a new mount point and configure as Advanced Disk.  
   Change SLPs to use the AdvDisk for backup and dup to tape. Expire after Dup will be best.
   Allow existing MSDP to empty out (expire), then remove MSDP from config.
   I am not entirely sure that more than one AdvDisk can be used (you can lookup in Admin Guide or online). If so, carry on with next step:
   Add /NBU_DSU1 as Adv Disk and change SLPs to use this for backup. Expire after Dup.  (keep an eye on disk usage)
   Allow AdvDisk on new volume to empty out (expire).
   Remove new volume AdvDisk from config.
   Create folders on new volume mount point as per Dedupe Guide, then config as MSDP.
   Change SLPs
   Remove /NBU_DSU1

---

i can't add the new partition as another PureDisk pool. if i choose to add it as a PureDisk, it keeps presenting me with the existing 9TB disk. so i added the 14TB as an AdvancedDisk.

is there any performance difference between PureDisk and AdvancedDisk? EDIT: found the answer and which i think with AdvancedDisk my disk performance should improve coz there'd be no on-the-fly compression.

in the above highlighted steps from you, is that necessary? i'm seeing now that with SLP, i can redirect the backups to go to the AdvancedDisk (14TB) partition. so that solved half of my problem. what i'll do is let dedup finish whatever backup images are left on the old 9TB partition and once done, i can just remove that partition (after moving the location of the catalog of course).

[manatee]

i did a test backup and it is saving to the new disk. but why directly under the root??

i'm seeing many .IMG and .INFO files created.

how to tell it to backup to a folder that corresponds to the name of the server it is backing up?

[Marianne]

There is a process described over here to add another mount point: 
https://www.veritas.com/support/en_US/article.000076751
(...crcontrol --dsaddpartition .....)

BUT, as per my previous post - you don't really want to do that because you need to get rid of current 9TB partition because of the bad performance.

I cannot comment on performance - MSDP is supposed to give good backup performance IF you follow best practice for dedupe backups. read from disk (duplication and restore) will always be slower than backup performance due to rehydration.

Advanced disk will probably give you relative good performance just because you have it on physically separate disk.
AdvDisk is simply 1-1 backup - same as backup to tape.
Because there is no dedupe, you need to watch space carefully.
Read performance will be better than dedupe and tape.

What makes you believe that your MSDP mount point contains 'the catalog'?
(after moving the location of the catalog of course)
ONLY MSDP database/catalog info is stored there. Once everything (on MSDP) has expired, there will be nothing left as far as MSDP catalogs are concerned.

Your NBU images catalog is located under /usr/openv/netbackup/db.  
UNLESS someone has manually moved them and created a symlink.
Easy enough to see with 'ls -l /usr/openv/netbackup/db' .
images will either be a directory (default) or symlink pointing to different location.

You can keep on using MSDP if you feel that dedupe is of no advantage in your environment. 

[Marianne]

---

@rino19ny wrote:

i did a test backup and it is saving to the new disk. but why directly under the root??

i'm seeing many .IMG and .INFO files created.

how to tell it to backup to a folder that corresponds to the name of the server it is backing up?

---

That is how Advanced Disk works... 
Similar to Basic Disk. Only difference is that you can have multiple volumes/mount points in the same disk pool and that you can use it in SLPs.

You cannot expect AdvDisk to work the same as MSDP. The technology is completely different.

[Marianne]

Another 2c from my side - if you do not 100% understand NBU structures, databases, folders where they exist and function of each (as described in 'Parts of NBU catalogs', then please... find a knowledgeable consultant to assist you.
We have a number of EXCELLENT guys in this community who offer consulting services. If I am not mistaken - on site and remote.

If your company has BCS (Business Critical support) from Veritas, your BCE will also assist.
At least with checking and verifying your intended steps.