reallocate the /etc/vx/cbr/bk , vg config backup file without any service restart ...
1. Create the directory to copy the vg config backup file . # mkdir -p /tech/vgconfigbackup/bk ( please must create the "bk" directory ) 2. Take the backup of scripts " /usr/lib/vxvm/voladm.d/lib/vxcbrlib.sh " # cp /usr/lib/vxvm/voladm.d/lib/vxcbrlib.sh /usr/lib/vxvm/voladm.d/lib/vxcbrlib.sh_bkp<date> 3. Made the required change care fully in below script . # vi /usr/lib/vxvm/voladm.d/lib/vxcbrlib comment the existing line "CF_BKUP_BASE_PATH" and change CF_BKUP_BASE_PATH to point to a new location. 4. Delete the all old vg configuration file backup from default location . 5. Take the new vg configuration backup and test 6. Check the new vg configuration file backup in new location .1.4KViews4likes3CommentsMigrating to a new SAN
We're in the process of moving to new datacenters. All servers will be moved over but the SAN won't. The SAN will be replicated to a new SAN in the new datacenters by our SAN admins. That means, the LUNs in the new SAN will be identical to the old, also the LUN numbers. Example output from'vxdisk list' on the current host shows: c1t50050768014052E2d129s2 auto:cdsdisk somedisk01 somedg online This disk will get same LUN nr, but the target name will probably differ as it's new hardware in the new DC. Will this work with Veritas SFHA? If not, is there any way to do this the way the datacenter project wants to? If I could choose to do this my way, I would presentthe LUNs on the new SANto my servers so that I could do a normal host based migration. Add the new LUN to the diskgroup and mirror the data, then remove the old LUN. However, I'm told that the hosts in the current datacenter won't be able to see the new SAN.Solved2.2KViews2likes3Comments