Applications that directly access the local Linux file system see the primary file tree and the secondary file tree as independent directories. The backup utility does not see the merged view of the file tree that the end user sees. Thus, backup tools can apply one backup policy to the primary file tree and a different backup policy to the secondary file tree. In a DST volume, the only operations that take place directly on the secondary volume are backup (or remove and archive) and restore functions.
Using shadow volumes allows backups of important data to be made faster and more frequently because you can apply different backup policies for the primary volume and secondary volume.
For example, the server administrator can partition the volume’s data into two categories:
Important data that needs to be maintained on quality storage and backed up frequently.
Less important data that can be stored on less expensive storage and backed up less frequently.
An analysis or inventory of a volume’s data shows that a large portion of it is seldom used. Having a shadow volume allows the server administrator to spend more on the most important data and spend less on the less important data. The frequently used data can be backed up nightly. The seldom-used data can be backed up weekly or monthly.
Getting the less important data out of the way enables the backups of your important data to run more quickly and efficiently. Partitioning your data in this way can significantly reduce the cost of hosting it.
Because the most important files are located in the primary storage area, disaster recovery can also be faster. The server administrator can restore the critical files by restoring the primary storage area first, then restore the secondary storage area. This lets users quickly get the files they need most, and they do not need to wait while files they do not usually need are restored. In addition, more fault tolerant replication solutions can be deployed for the primary storage area where it matters most.
Ensure that policies are not being run during the backup window.
You can restore the data separately to each volume by using the backups you made of each area. If ShadowFS is running, you can also restore the data by using the ShadowFS local mount point in /media/shadowfs/volumename that presents a merged file tree that includes both volumes. The advantages and disadvantages of each restore option are described below.
Consider the following advantages and disadvantages when restoring data separately to the NSS volumes. You restore data backed up from the primary path to the primary NSS volume. You restore data backed up from the secondary path to the secondary NSS volume.
Files are restored directly to the primary volume and secondary volume where they were when the files were backed up, so there is no need for the information to be transferred again through policies.
There is no performance hit when you restore directly to each volume like there is when restoring to the ShadowFS file tree.
The restoration size is not an issue because you are restoring to the proper volume rather than though the ShadowFS file tree view.
You can back up the NSS volume by using the NSS Extended Attributes (XAttr) settings to preserve the NetWare metadata (netware.metadata) for file system rights and attributes, and restore that information to each volume as you restore data. For information about XAttr, see Extended Attributes (XAttr) Commands
the OES 2018 SP3: NSS File System Administration Guide for Linux.
Ensure that no policy runs are in progress while data is being restored.
Potential conflicts might occur if you restore duplicate versions of the file on each of the volumes. The duplicate files are resolved by DST global policies instead of being resolved by the backup software. By default, the duplicate files are allowed to coexist, and a conflict message is broadcast to users. For information about duplicate file resolution, see Section 7.3, Resolving Instances of Duplicate Files.
When you restore partial data, you need to know whether the most recent version of the data is located on the backup for the primary volume or the secondary volume.
If ShadowFS is running, you can also restore the data by using the ShadowFS local mount point in /media/shadowfs/volumename that presents a merged file tree that includes both volumes.
The backup software sees both volumes through the merged file tree view. You can restore the primary volume, secondary volume, or both volumes through this view, and let any duplicates be handled by your backup software.
Whether the data is on the backup for the primary volume or the backup for the secondary volume, if both are restored, the users’ data is restored.
Ensure that no policy runs are in progress while data is being restored.
The FUSE technology used by ShadowFS is slower than using the NCP view, but the backup software cannot see the NCP view.
If you back up the NSS volume by using the NSS Extended Attributes (XAttr) settings to preserve the NetWare metadata (netware.metadata) for file system rights and attributes, this information cannot be restored through the shadowfs merged view of the data because XAttr requires that the destination location be an NSS volume. The shadowfs view is a mount point and is not seen by the backup software as an NSS volume. For information about XAttr, see Extended Attributes (XAttr) Commands
the OES 2018 SP3: NSS File System Administration Guide for Linux.
All files restored through the ShadowFS file tree view are copied to the primary volume. The data that you restore from the backup for the secondary volume is not returned to the secondary volume until you run policies or use inventory scans to move the data back to the secondary volume.
Because all data is restored to the primary volume when you restore through the ShadowFS file tree view, it is possible to run out of space. The primary volume must be large enough to accommodate holding both volumes worth of data unless you restore in phases; that is, restore some directories, then shift data to the secondary, then restore more directories.
A backup utility can use the /etc/NCPVolumes XML file to easily locate each mounted NCP volume and find its primary and secondary file trees. The file contains an entry for each mounted volume. It lists the volume’s name and the path for the volume’s primary file tree (PRIMARY_ROOT). If the volume is a shadow volume, it also shows the path for the secondary file tree (SHADOW_ROOT).
For example, the following XML entry defines the DST shadow volume named VOL1. The volumes are NSS volumes, with VOL1 as the primary storage location, and ARCVOL as the secondary storage location.
<VOLUME> <NAME>VOL1</NAME> <PRIMARY_ROOT>/media/nss/VOL1</PRIMARY_ROOT> <SHADOW_ROOT>/media/nss/ARCVOL</SHADOW_ROOT> </VOLUME>
You can use Novell Storage Management Services tools for backup and restore of NSS volumes. You can back up each NSS volume separately, and restore them separately. You need to be aware of the relationship on restore because you can get duplicate files. However, the mechanics of the backup and restore with SMS are the same as they are with any NSS volume. Refer to the SMS documentation for information about how to use SMS for NSS backup and restore.
The NSS Backup attribute must be enabled on the NSS volumes if you use SMS tools for backup of NSS volumes. The attribute is enabled by default when you create a new NSS volume.
To enable the Backup attribute for an existing NSS volume:
In iManager, click Storage > Volumes.
Select a server to manage to view a list of the NSS volumes on it.
In the Volumes list, select the volume that you want manage, then wait for the page to refresh to show the volume’s details.
Click Properties to view the settings for the volume attributes.
On the Attributes tab, select the Backup attribute, then click Apply.
If you plan to use a backup utility with DST, you might need to add an NSS attribute that allows for backing up and restoring file system trustee assignments, trustee rights, and inherited rights filters. NSS provides the nss /ListXattrNWMetadata switch to enable this capability. For information, see ListXattrNWmetadata Option
in the OES 2018 SP3: NSS File System Administration Guide for Linux.