Synchronization and Direction Modes

One-Time vs. Continuous Synchronization and Allowable Directions

IBM Aspera Sync offers two modes of operation: one-time ("on demand") synchronization and continuous synchronization.

Mode	Description
One-time synchronization	In this mode, async performs synchronization of the endpoints, and exits. If an existing snapshot database exists from a previous run, async uses the existing snapshot to determine changes, unless specifically instructed to drop the snapshot and scan the file system again (see the -x option in async Command-Line Options). This mode should be used for one_time operations, or for periodic, scheduled synchronizations where file systems do not support event-based change notification. For the latter, async can be scheduled as a cron job to run periodically.
Continuous synchronization	In this mode, async performs synchronization of the endpoints and continues running. As file system updates occur (i.e., files or directories are added, deleted or modified), async detects these changes and synchronizes with the peer endpoint. Continuous mode requires local file systems that support change notification.

Mode

Description

One-time synchronization

In this mode, async performs synchronization of the endpoints, and exits. If an existing snapshot database exists from a previous run, async uses the existing snapshot to determine changes, unless specifically instructed to drop the snapshot and scan the file system again (see the -x option in async Command-Line Options). This mode should be used for one_time operations, or for periodic, scheduled synchronizations where file systems do not support event-based change notification. For the latter, async can be scheduled as a cron job to run periodically.

Continuous synchronization

In this mode, async performs synchronization of the endpoints and continues running. As file system updates occur (i.e., files or directories are added, deleted or modified), async detects these changes and synchronizes with the peer endpoint. Continuous mode requires local file systems that support change notification.

The table below describes each of the Sync deployment models.

Mode	Description
Uni-directional	Similar to rsync, Aspera Sync supports replication of files and directories, and any updates to these (including deletions, renames, moves, copies, etc.) from a source to a target. The direction of replication can be specified as a "push" or "pull" operation, relative to the initiating host. Once a snapshot is taken after the first replication, all file system updates are recognized against this snapshot, and no comparison of source to target over the WAN is performed (as in rsync). Sync supports most of the same uni-directional synchronization options as rsync, such as include/exclude filters, overwrite only if newer, symbolic link handling, and preservation of file system ownership and timestamps (access, create, etc.).
Bi-directional	Sync can also be run in a bi-directional mode, which supports the replication of all file and directory updates between the peers. For any case in which the most recent version of an update cannot be reliably determined, or when a file changes on both endpoints concurrently, Sync flags the update as a conflict and leaves the peer file systems in their present state (and in conflict). Files in conflict can be reviewed using the asyncadmin command-line tool (see asyncadmin Command-Line Options). In this version, it is up to the operator to resolve conflicts manually.
Multi-directional	Sync also supports multi-directional synchronization scenarios, in which multiple endpoints need to be kept in sync, including the following: Hub-and-spoke synchronization: A core source (hub) server or cluster replicates to N-number of endpoints (spokes). This configuration can support distributed workflows, content delivery networks, remote- or branch-office replication, and any other scenario requiring concurrent replication to multiple endpoints. Collaborative file-based working: Sync can be used to synchronize remote file stores over the WAN where the file content is being updated concurrently. It is ideal for sync workflows that rely on large unstructured files or file sets, for which traditional caching/compression or de-duplication strategies offer no significant benefit. In multi-directional scenarios, one Sync session (one async process execution) is required for each remote peer with which synchronization needs to be done. Any number of async processes can be run concurrently, and any number of peers can be synced concurrently. The model assumes peers that are synchronizing are in an acyclic graph topology, meaning that a downstream peer is not configured to sync "back" in a loop to an upstream peer.

Mode

Description

Uni-directional

Similar to rsync, Aspera Sync supports replication of files and directories, and any updates to these (including deletions, renames, moves, copies, etc.) from a source to a target. The direction of replication can be specified as a "push" or "pull" operation, relative to the initiating host. Once a snapshot is taken after the first replication, all file system updates are recognized against this snapshot, and no comparison of source to target over the WAN is performed (as in rsync). Sync supports most of the same uni-directional synchronization options as rsync, such as include/exclude filters, overwrite only if newer, symbolic link handling, and preservation of file system ownership and timestamps (access, create, etc.).

Bi-directional

Sync can also be run in a bi-directional mode, which supports the replication of all file and directory updates between the peers. For any case in which the most recent version of an update cannot be reliably determined, or when a file changes on both endpoints concurrently, Sync flags the update as a conflict and leaves the peer file systems in their present state (and in conflict). Files in conflict can be reviewed using the asyncadmin command-line tool (see asyncadmin Command-Line Options). In this version, it is up to the operator to resolve conflicts manually.

Multi-directional

Sync also supports multi-directional synchronization scenarios, in which multiple endpoints need to be kept in sync, including the following:

Hub-and-spoke synchronization: A core source (hub) server or cluster replicates to N-number of endpoints (spokes). This configuration can support distributed workflows, content delivery networks, remote- or branch-office replication, and any other scenario requiring concurrent replication to multiple endpoints.
Collaborative file-based working: Sync can be used to synchronize remote file stores over the WAN where the file content is being updated concurrently. It is ideal for sync workflows that rely on large unstructured files or file sets, for which traditional caching/compression or de-duplication strategies offer no significant benefit.

In multi-directional scenarios, one Sync session (one async process execution) is required for each remote peer with which synchronization needs to be done. Any number of async processes can be run concurrently, and any number of peers can be synced concurrently. The model assumes peers that are synchronizing are in an acyclic graph topology, meaning that a downstream peer is not configured to sync "back" in a loop to an upstream peer.