Page tree
Skip to end of metadata
Go to start of metadata


The purpose of this document is to explain some general guidelines that when observed will increase the effectiveness of backups and restores of a RemoteWare system.


A successful disaster recovery policy requires a well-planned and tested backup procedure. This procedure should include the following: what to backup, directions for performing backups, when to perform backups, testing the backups, and directions for restoring the backup.


The RemoteWare system can be extremely complex and thus a well thought out plan is required to perform successful backups of the system. First, however, one must understand how the RemoteWare components work together. Below is a list of common terms used when discussing a RemoteWare environment:

RemoteWare Communications Server - This server hosts the communications pieces of RemoteWare and performs the actual connections to the clients or accepts the inbound connections from the clients.

RemoteWare Data Drive Server - This server hosts the main data storage components of a RemoteWare system. It consists of 5 main directories: \ECF, \Node, \Nodesys, \Sysfiles, and \Worklist. It may contain more depending on the other optional RemoteWare components installed. The RemoteWare Data Drive may be installed on its own server or may be installed locally on the  RemoteWare Communications Server.

RemoteWare Cluster - A group of RemoteWare Communications Servers grouped together and pointing to a single RemoteWare Data Drive. The RemoteWare Data Drive acts as the cohesive component that binds all the servers to one set of clients and allows the servers to act as a single RemoteWare system.

RemoteWare Client - A RemoteWare client is a machine running a specifically supported Operating System on which the RemoteWare Client software is installed.

Microsoft SQL Server - When discussed in the context of a RemoteWare system, a Microsoft SQL Server, or just SQL Server, acts as the storage mechanism for Logging, Messaging header information, Inventory storage, and Subscriber and Workshop application assignments.

RemoteWare Workstation - A Windows machine running the RemoteWare Workstation software. This software has the look and feel of the server environment but contains no communications resources so clients cannot connect to this machine. The machine is an administrative console. There can be up to 10 RemoteWare Workstations in a RemoteWare System.

What needs to be backed up

In order to perform a Complete Backup of a RemoteWare system so that the administrator will be able to restore it to its existing state the admin must backup all components necessary to restore the system to its current state. This seems simple enough but includes a fair amount of detail. So the Question is, "What specifically do we backup?"

The answer is the administrator should backup the following items:

  • Each RemoteWare Communications Server should have a complete backup including all Operating System files and RemoteWare files as well as the Registry.
  • The RemoteWare Data Drive machine needs only all the files that actually relate to the RemoteWare system backed up. These files and subdirectories are located in the path entered during installation. The data drive path, <ServerData>, will contain the 5 main directories in bold, and may contain the other directories depending on the version of RemoteWare, the configuration, and which add-on components are installed:
  • \Backup
  • \Data
  • \ECF
  • \Inventory Manager
  • \ldinv
  • \Node
  • \Nodesys
  • \results
  • \Subscriber
  • \Sysfiles
  • \System
  • \Toolkits
  • \Worklist
  • \Workshop
  • Each RemoteWare Workstation should have a complete backup including all Operating System files and RemoteWare files as well as the Registry.
  • Microsoft SQL Server should have each database that is used by the RemoteWare system backed up. This includes the scheduling database, and the Logging database

How to backup the RemoteWare system

The main thing to remember when backing up the RemoteWare System is that all RemoteWare services on all RemoteWare Servers and Workstations should be stopped prior to performing the backup.

Method 1

The following steps detail the recommended method for backing up the entire RemoteWare System.

  1. Shutdown the RemoteWare service on each RemoteWare Workstation.
  2. Shutdown the RemoteWare service on each RemoteWare Server.
  3. Run a backup program to backup the RemoteWare Data drive files.
  4. Run a backup program to backup all the files (including the Operating System files and the RemoteWare files) and the registry on each RemoteWare server.
  5. Backup each SQL Server database used by the RemoteWare System. Each of these steps must be performed every time a backup is run. This will save the entire system they way it exists now and will allow the admin to restore it to the exact state in which it existed at the time of the backup.
Method 2

The administrator can use a modified version of these steps to save time and backup space. This method allows the admin to run the above steps once or at longer intervals and then backup just specific parts of the RemoteWare System that have changed at shorter intervals

  1. Complete the above steps at least one time to ensure a complete system backup.
  2. At each shorter interval, backup the following information that has changed using the following steps:
    1. Shutdown the RemoteWare service on each RemoteWare Workstation.
    2. Shutdown the RemoteWare service on each RemoteWare Server.
    3. Run a backup program to backup the RemoteWare Data drive files
    4. Run a backup program to backup each SQL Server database used by the RemoteWare System.

When to perform a backup 

When to backup depends on what is installed, how much the admin can afford to lose if the system goes down and how often the system can be brought down to perform backups. One recommended solution is to run a Complete Backup (Method 1) once a week and then daily perform the Partial Backup (Method 2). This will allow the admin to have a system the admin can restore to the state in which it existed the day before. With this procedure, at most the company will loose at most one day's worth of changes should a disaster occur. However the admin can perform the Partial Backups more frequently, perhaps every 12 hours. That would allow the recovery of data up to 12 hours old. Newer changes will be lost

Restoring the backup

Restoring the Backup is a straightforward process that consists of two main steps.

  1. Restore each machine with the last Complete Backup (Method 1).
  2. If using partial backups as well; after step 1 has been completed on each machine, restore the last Partial Backup (Method 2) to each machine.

Testing the backup

The administrator should periodically test the backups the admin has performed to ensure they can be restored and there are no problems with the backup equipment. In addition restoring a backup in a test scenario will ensure the backup procedure in place works and will inspire confidence that the admin can perform the procedure while under the pressure of a live disaster recovery situation.

Common Pitfalls

Several common shortcuts to performing backups result in major problems when it comes time to restore the data.

  1. The first common shortcut, or mistake, is having some or all of the RemoteWare services up and running while performing the backups. RemoteWare locks several files for exclusive use and does not allow other processes to access these files. Several of these files change quite often. One example is the scdfile.dat that by design is often updated many times per second. Backup programs, including those with open file access cannot reliably backup these files. Failure to stop all the RemoteWare services on all Servers and Workstations will ensure that this file, and many others, is held open for exclusive use. The net result is that the backup program will not be able to reliably backup this file and when the time comes for a restore the company will have an inconsistent system that may not be recoverable.
  2. The second most common pitfall of any backup solution is failure to test the restore process. Understanding the restore procedure is just as vital to a successful Disaster Recovery plan as the backup procedure. In addition to understanding the restore procedure familiarity with performing the restore procedure from practice will ensure the restore can be performed with minimal problems and in a timely fashion on a downed production server. The final reason to periodically test the restore process is to ensure the backup devices and backup medium are not damaged or working incorrectly.

Recommended backup programs

In general, any backup application that can backup and restore files plus backup the Windows registry will work for the RemoteWare backups.

Although some backup applications claim that they can backup files while in use (i.e. leaving the RemoteWare services running will have numerous file in use), SAP advises that the administrator completely tests a complete system backup and full system restore with this type of application before it is run in a production environment. There is always a risk of file corruption when running the backup with the services running.

Related Content

Related Documents

The GEN utilities can be used to enhance the backup and restoration capabilities of RemoteWare. 


  • No labels