Migration via external interposition
Shadow filesystem semantics during migration
Snapshots of shadow filesystems
Replicating shadow filesystems
Migration of local filesystems
Testing potential shadow migration
Migrating data from an active NFS server
Filesystem and project settings
Protocol access to mountpoints
Non-blocking mandatory locking
Create a project level snapshot
Create a share/LUN level snapshot
Rolling back to a Snapshot (BUI)
Rolling back to a Snapshot (CLI)
Setting the Scheduled Snapshot Label (CLI)
Remote Replication Introduction
Project-level vs. Share-level Replication
Modes: Scheduled or Continuous
Including Intermediate Snapshots
Cloning a Package or Individual Shares
Exporting Replicated Filesystems
Reversing the Direction of Replication
Destroying a Replication Package
Reversing Replication - Establish Replication
Reversing Replication - Simulate Recovery from a Disaster
Reversing Replication - Resume Replication from Production System
Cloning a Received Replication Project
Snapshots and Data Consistency
Replicating iSCSI Configuration
Each project has protocol-specific properties which define the behavior of different protocols for that shares within that project. In general, shares inherit protocol-specific properties in a straightforward manner. Exceptions and special cases are noted here. For protocol issues, refer to Troubleshooting Protocols.
NFS share properties are inherited normally, and described in the shares documentation.
|
No two SMB shares on the same system may share the same resource name. When filesystems inherit resource names from a project, the share's resource name is constructed according to these rules:
|
iSCSI properties are not inherited.
HTTP share properties are inherited normally, and described in the shares documentation.
FTP share properties are inherited normally, and described in the shares documentation.