Performing a Remote Backup

Perform a remote backup using the sample recovery plan as an example.

Once your database is properly mirrored with transaction logs on separate disks, perform an initial backup of the consolidated database. Use the tools in the <SUP_HOME>\Servers\UnwiredServer\SQLAnywhere11\BIN32 directory. Add this directory to your PATH.

Note: In some configurations, the dbvalid and dbbackup commands do not work remotely.

Use the dbvalid utility to validate the integrity of the database. The validation must be performed when there are no active connections to the server. Use the dblocate utility to locate the actual name of the database server in a particular installation. Typical names take the form of <clustername>_primary. The clusterdb is present if Unwired Server has been configured to run as a cluster.
```
dbvalid.exe -c "DBF=uaml.db;UID=dba;PWD=SQL"
```
```
dbvalid.exe -c "DBF=clusterdb.db;UID=dba;PWD=SQL"
```
On Computer B, verify that SQL Anywhere software is installed, and the PATH is set. If you are running Sybase Unwired Platform as a cluster, you already have that software installed under the Sybase Unwired Platform installation directory. Otherwise, install another copy of Sybase Unwired Platform there. You need not add this installation to your cluster; you can even use a Developer Edition installation if you like.
Once Computer B is set up with the SQL Anywhere tools, run:
```
dbbackup -c "ENG=<clusterName>_primary;DBN=uaml;UID=dba;PWD=SQL" \SQLAnybackup
```
```
dbbackup -c "ENG=<clusterName>_primary;DBN=clusterdb;UID=dba;PWD=SQL" \SQLAnybackup
```
This creates uaml.db, uaml.log, clusterdb.db, and clusterdb.log in the \SQLAnybackup directory on Computer B.
As a precaution, validate the backups are suitable for recovery:
1. On Computer B, create a temporary working directory (such as \tmp).
2. Under the temporary directory, create an identical directory structure for the two log locations. You may need to use the subst command to map local directories to drive letters used on Computer A.
3. Copy *.log to these locations.
4. Run dbvalid on the \tmp copy of the .db file. WARNING: Do not run dbvalid on the backup copy itself (in the \SQLAnybackup directory of this example). The command runs, but corrupts your .db file so it cannot be used in recovery.
5. If validation succeeds, you are assured that your backup in \SQLAnybackup can be used for recovery. You can delete the files in the \tmp and log directories. If validation fails, the backup is not usable for recovery and you should try again.

Next

Sybase makes these recommendations for setting up your backup schedule:

Schedule backups from Computer B for some reasonable frequency so that, in the worst-case failure of a complete failure of Computer A, you do not lose too many transactions.
Perform adhoc backups when there has been some major deployment of new Mobile Business Object packages to Sybase Unwired Platform. Otherwise you may lose those packages and have to redeploy them.