Absent Member.
Absent Member.

Best practice? > Consolidate DST to new server

On some branch offices we're running DST to move files and folders older 2 years to another device.

Now, we decided to consolidate the data from shadow and active volume to a new server.
But this task is not as easy as it seems for the first look.

The servers are very sensible and we have to minimize downtime as less as possible. As times goes by, DST collected hundreds of gigabytes to the shadow volume. It will take some time to copy over the wire.

Good job for Migration Tools .. copying data while filesystem in use, down server, make a SYNC to copy slight delta and go online again.
But ...

Problem is the data on DST shadow volume. Before migration takes place, I deactivate all running DST policies to freeze the state of the shadow.

The shadow volume cannot be reached by Novell-Tools. All of them needs NCP access, but NCP has to be deacitvated for running DST. That makes sense, otherwise users may "see" (and modify) the shadow, because its a mirror with all trustees and filesystem rights.

What may I use to transfer the data from shadow to the new volume while DST is in use? Similar to migfiles, where the filesystem can be in use while migration?

I would be grateful for every hint or advice
Hardy Dockhorn
Novell admin in northern germany
Labels (1)
3 Replies
Absent Member.
Absent Member.


there is a small description in the documentation for OES
(mig_tools_lx.pdf for OES11SP2 p.101 ff) chapter 16.2.5 "Data Migration
for DST Volumes"(altough i have never done this by myself so far).
Deactivating DST policies before starting the migration as first step is
mentioned there too (as you have done it).
Then the second step in order to migrate the data from all (primary and
secondary) the volumes of the source server to the target server you
have to remove the shadow volume relationship on the source server.
Removing this relationship is described in the "OES 11 SP2 Dynamic
Storage Technology Administrion Guide" (stor_dst_lx.pdf; chapter:
Removing the shadow volume relationship for a clustered/non-clustered
DST shadow volume).
Documentation can be found on https://www.novell.com/documentation/oes11/.


Burkhard Wiegand
Debeka-Versicherungen Koblenz

Absent Member.
Absent Member.


.. thank you for your response.

Yes .. I've seen OES-Doc but that is not, what I want to do. I dont want to disturb DST while migration. Users should and must have access to all files, including that, residing at shadow volume.
Obivously there is no supported way to migrate files from DST shadow to another server during working hours.

If I reactivate NCP to get migfiles working, I open the access to the shadow to all NCP Clients. With other words: to all workstations with Novell Client. Everyone would be able to browse Network Environment and could map folders at the shadow. This may taint data-integrity of the shadow file system. I dont want to allow that. At the other side I dont know, if DST still works, if NCP access is (re-)enabled. This configuration for running DST is not supported.

The next alternative would be, to do the job while offline hours for the users. Because the shadow is quite huge, it will take some time to complete. I have to request a Maintenance Window to get the job completed. Not easy ..

For normal, NCP accessible data, Novell gave us "Migration Toolkit", making one, two or so many as you want Pre-Copies to transfer the giant, static block of data. For to finish migration I can use SYNC, which will transfer modified data since last "Pre-Copy" in a short offline time. Thats what I want to have for the shadow file system too, letting the old server run as he ran all the time before, no changes, no reconfigurations, no risk. And copy the huge data block while working hours.

The very best would be a peace of software, which simulates Novell Client at server side, having the same "sight" to the data as the Novell Client. This would be useful for backup too. We found no way to backup the data from shadow using SMDR/TSA. We had to read the data with native LINUX Tools, losing all enhanced Netware Attributes like Trustees, etc. Thats the main reason to get rid of DST in future. Data at shadow is stored in a "Black hole" .. thats bad.

Do you have DST at your servers? How do you handle that?

Hardy Dockhorn

PS .. if you're interested in knowledge sharing, you may contact me in german via my eMail address
Absent Member.
Absent Member.


we have DST only in a test evironment realised on clustered pool. These
data are backed up by Commvault Simpana and we are able to use "nss
/ListXattrNWMetadata" and "nss /CtimeIsMetadataModTime" switches in
nssstart.cfg to back up metadata of nss like trustees. (see NSS
Filesystem Admin Guide chap. 27.4 "Using Extended Attributes (xAttr)
Commands"). My knowledge for DST is purely from documentation and the
way Novell suggested a migration of DST-volumes is to break the shadow
relation and mount the shadow volume as ncp volume so that the
miggui-tools for instance is able to "see" and migrate the data. Given
that the directories and trutees are the the same on primary and show
volume that should be possible. But users may have to "wait" until the
data from the shadow is tranfered to the new volume but that is data
that is "seldom" used according to your policies.
Unfortunately it not as straight as a normal migration of NSS-Volumes
without DST.

Regards Burkhard
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.