Database Dumps

ADAM will create snapshots of the database at predefined times during the day. Snapshots are kept for differing lengths of time:

The numbers of backups and the frequency that the daily backups are taken are controlled in the Site Settings on the Cron tab.

These backups are not much use by themselves. They exist on the same machine as the actual database and so if there is a physical machine failure, it is possible that your backups will be lost too. For this reason, it is incredibly important that your backups are copied to a different physical machine at the very least.

ADAM does provide an FTP mechanism, discussed below.

Database FTP Backups

ADAM can transfer your backups to an FTP server automatically. The settings to configure this is done in the Site Settings, under the Cron tab.

FileZilla provide a very simple and easy to configure FTP server for a Windows environment, if you need one. IIS also has FTP capabilities.

Document Repository FTP Backups

In to Site Settings, there is a setting for document repository backups. These can be configured separately to the Database FTP Backups referred to above. The settings are found on the Cron tab:

The main reason that you may want to use two different user accounts for these is that the document repository user requires a little more in the way of privileges. The FTP for database backups simply requires "write" privileges to the destination folder. The FTP user for Document Repository, however, requires to be able to overwrite files on your server (this is in case they change, as with reports that are refreshed).

Separate times can also be set for FTP backups vs DocRep backups. Backing up documents once a day should be sufficient.

When backing up the document repository, ADAM will upload in bursts of 3 minutes. If there are large numbers of files that can't be uploaded within 3 minutes, the job will resume the next time the cron process is called, until all files are uploaded.

ADAM remembers the modification time of the last file it uploaded and on subsequent runs will begin at that point.

Note that if you are uploading to a server that is located behind a NAT firewall, you may need to turn on the PASV transfer option.

There are a few caveats with this experimental feature that you need to be aware of:

  1. There is currently very little in the way of error checking. If one file fails in the middle of transfer, there is a significantly good chance that ADAM will move on past it and, because its modification time is now in the past, is unlikely to attempt uploading it again. You are encouraged to perform periodic checks to ensure that the number of files on the server and in your backup location match.
  2. This process will only upload files ending in ".dat" in the document repository folder. No cross-checking is done with the actual database table. This shouldn't have any significant effect, except perhaps for deleted files. These will not be deleted from the backup location.
  3. There is currently no way to "reset" the backup and back everything up from scratch.