Example Architecture A should give you a good idea of the diverse number of systems that can be managed with this type of architecture. Wireless systems and users operating connections to your network through firewalls and VPN can also be managed. In fact almost anything that attaches to your network and is visible to a Windows system can be managed and backed up. The Indigo Backup software acts in a similar way to a smart client and backs up the systems (and associated peripherals) that it is install upon. The Indigo Grid software acts in a similar way to a server and controls/monitors each Indigo Backup 'Smart Client'. The Indigo Grid software can be set up as either a Grid Master or a Grid Slave. The Grid Master continually scans and administers you backup system, it then sends the results of its scans to the Grid Slave for analysis. In the above example the Grid Master is located on the server, and it sends the results of it's scans to the Grid Slave located on the Backup Administrator Client computer. The optimal arrangement for the backup system is shown where two servers are used, one as a system onto which the users backup their systems, and one administration server which holds the Indigo Grid database. Two servers are not required as the Grid database can be located on any system on the network; however, it is desirable, as a crash of the backup server would not effect the running of the Indigo Grid administration system. In this way monitoring of the backup system and updates to it would be uninterupted.

Example Architecture A should have shown you what you can backup, but Example Architecture B shows you a real example of a working Indigo Backup Network using the Grid system. An Indigo Grid set up as a Master is placed on the Backup Admin Server. No user files are backed up to the this server, and it only holds the Indigo_Admin database. Instead all the users Indigo Backup systems are set to backup to the Backup Server and to use a customised Indigo Admin database located on the Backup Admin Server. The Indigo Grid Master on the Admin Server is set to monitor the Indigo Admin database and set up to monitor backup share health and size on the Backup Server. It is set to conduct monitoring between 2 am and 4 am on Monday morning when the least number of employees are using the network to minimise network impact. The Indigo Grid master is also set to email the results of it's monitoring to the primary admin PC. It has an email clent set up on it for this purpose. Indigo Grid automatically interfaces with this client to send the data files. Because the Indigo Grid master and Indigo Admin database is not located on the backup server, should the backup server crash the Indigo Grid system can still continue monitoring and will pick up the crash in it's data files.

The primary admin PC has a copy of Indigo Grid loaded onto it but set up as a slave. They can then load the Indigo Grid emailed data files on their local copy of the Indigo Grid software, once loaded the results can be used in exactly the same way as they could be on the master.

To improve reliability of the system and increase redundancy a secondary admin PC is used to allow access to the Indigo Grid master when the employee serving as the primary administrator is unavailable. During such times the Indigo Grid master sends the results of it's monitoring to the primary admin PC in the normal way, but the primary admin PC has it's email client set up to forward the email to the secondary admin PC. The secondary administrator can then load the Indigo Grid emailed data files on their local copy of the Indigo Grid software which has been set up as a slave.

In certain circumstances the primary administrator has to work out of the office. A tertiary admin PC (or laptop) running a copy of Indigo Grid as a slave is set up for this purpose. When the primary administrator is out of the office he sets up the primary admin PC's email client to forward any emails from the Indigo Grid master to the tertiary admin PC. This tertiary admin PC only needs access to an email connection to receive the data files from the Indigo Grid master by email. These data files can then be loaded onto the slave and viewed.

In this way the architecture fulfills the main goals of any secure backup system:

1. Security
2. Reliability
3. Redundancy
4. Maintainability
5. Automation