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


  • Hello,

    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


    Burkhard Wiegand
    Debeka-Versicherungen Koblenz

  • Burkhard

    .. 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
  • Hello,

    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