Multiple Databases (Snap DB)

Specifying the database directory.

Print this page
This topic covers the process of specifying the database directory on the command line by using -b (local) and -B (remote). Snap DB does not work on CIFS, NFS, or other shared file systems mounted on Linux; therefore -B and -b must specify a directory on a file system physically local to the endpoint host. The first concept to grasp in this topic is that async creates a private directory (~private-asp) for the following purposes: Since the database directory can be specified on the command line using -b (local) and -B (remote), there will be a ~private-asp directory in the sync directory (used for transfer cache) and a ~private-asp directory in the -b/-B directory that stores the DB. Note that because multiple sessions can sync the same directory or specify the same DB directory (-b/-B), async creates a subdirectory under ~private-asp for each session (with the name specified using -N). The session name only allows standard alphanumeric, plus the "_" and "-" characters, so that it can be created as a directory. This subdirectory is created on both sides if needed by the direction of the transfer and DB location (see below for details).

Each async session must have a unique name (as specified with -N). If multiple sessions sync the same directory or specify the same DB directory (-b/-B), then the session names must be unique. The snapshot DB records the session name and the sync directories (local and remote). If you initiate a second async session with the same name, using the same sync directory on one end but a different directory on the other end (or both directories are different, but the DB location is the same), async will fail.

Note: You can sync between a Windows endpoint and a Windows server, as well as between a Windows endpoint and a Linux server. In async, the path separator "/" works equally well on Windows and other platforms. The path separator "\" works only on Windows. The examples below use "/" uniformly.

Example 1: Bi-directional async  

> -N ex1 -b c:/db -B d:/aspera/var -d c:/data/users -r admin@server:d:/storage/users -K bidi

The above command creates the following:

On the local computer (initiator):

On the remote computer (reactor):

Example 2: Uni-directional async

> -N ex2 -b c:/db -B d:/aspera/var -d c:/data/users -r admin@server:d:/storage/users -K push

The above command creates the following:

On the local computer (initiator):

c:/db/~private-asp/ex2/snap.db

On the remote computer (reactor):

d:/aspera/var/~private-asp/ex2/snap.db

d:/storage/users/ex2 (for transfer cache)

Changing Direction Between Runs

Changing direction between runs is not allowed. async will fail with an error message and you must run it with --reset or provide a new DB directory.

Starting up when a snapshot DB is missing

An async session cannot start when only one of the snapshot DB is present. If this is the case, you must either clean the DB or start async with --reset. The DB is located under the regular private directory by default, although its location can also be specified by startup parameters. Behavior with respect to presence of the private directory and DB file are as follows:

On the client:

  1. If the private directory doesn't exist, create it.
  2. If the database directory doesn't exist (meaning the database doesn’t exist), create both, and remember "there was no DB."
  3. If the database file doesn't exist, create it and remember "there was no DB."
  4. Tell the remote whether the DB existed.

On the remote:

  1. Same as client 1, 2, and 3.
  2. Determine if "there was no DB."

If there is a discrepancy (local DB exists, but no remote; or, remote exists but no local), tell the client there is an error. If a subsequent run specifies different DB directories, the above behavior is preserved. In other words, even if a DB exists in the regular private directory or elsewhere, it assumes "there was no DB" if there isn’t a database in the specified directory.

Deleting the snapshot DB during synchronization results in undefined behavior

To recover, stop async, delete the DB on the other side as well, and restart.