Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
Myth24601
New Member.
1169 views

DST Shadow volume as a Migration vehicle

I know that normally you would use one of the migration utility to migrate a volume from one disk to another but is there any reason that the DST Shadow volume system couldn't do it?

In my case, I want to migrate an nss volume to a different disk on the same server. I could setup the new NSS volume as a shadow, let everything migrate at my leisure using the policies while users still have access to the system (it is a fairly large volume 1.5TB). Once I get most everything moved, I kick off the users then run one final policy to move anything that is left then remove the shadowing, change the login scripts to point to the new server and finally dismount the original volume.

I assume this would work but I am wondering if I am missing something. there seems to be a trustee_database.xml file on the shadow so I would assume all the rights would transfer over.
Labels (2)
Tags (2)
0 Likes
2 Replies
Knowledge Partner
Knowledge Partner

Re: DST Shadow volume as a Migration vehicle

You could do something like that, yes. Assuming it's on the same server that is. The only gotchas I can think of is things like home directories would have to be redone in eDir and if you have any ZEN NAL app objects that use that UNC path, they MAY have to be changed.

I've never done it myself, (just something similar), but it should work. Just be VERY VERY careful that all the stuff is moved over. Unfortunately DST doesn't do a good job (IMO) of moving anything marked read-only and it leaves the directories there too, I believe. It'll move the trustee.xml file and other things, but not sure if you're better off rebuilding that after the fact either.
0 Likes
Knowledge Partner
Knowledge Partner

Re: DST Shadow volume as a Migration vehicle

Actually now that I think about it, if this is an existing OES2 SP2/SP3 Linux box, I'd probably just make a new volume and use the miggui to migrate the files over. then do a sync for the final copy when you kick everyone off.

But that's just me.

I can't remember if SP2 or SP3 is where they added the ability to miggui within the same server.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.