Our Services  Software Tutorials My Indigo Contact Us
                           
  Indigo Prime - The  Data  Management, Backup and Recovery Experts
Business Software FAQ & Tutorials My Indigo Contact
           
 
Link to this site Send to a friend Bookmark this Page
 
     

Example Full Corporate System

An example of how Indigo can be used to fufill the requirements of a large business wide area network. Not every feature of Indigo is used but this example will show you how to impliment the main architecture of the system.

Basic Indigo Backup Features

Secure
Remote Administration
Scalable and Predictable
Custom setup and rollout options
You require copies of Indigo Backup, 2 or more copies of Indigo Grid, client PC or laptops running Windows, 1 server running Windows, 1 additional server.
Consider using a simpler Indigo Backup setup if you do not require this level of protection.
This system has been tested on mixed WAN networks with a potentual test base of over 8,000 mobile and fixed users.
Suitable for Indigo Backup versions 1 to 5, and Indigo Grid versions 1 to 2
.


Indigo Backup Features You Should Consider Using

Network Locking - Specify subnets on which Indigo Backup may be active to prevent backup over low speed lines such as VPN
Predictive Monitoring - Get advanced warning of any additional modifications that you may need to make to your backup network to keep it running smoothly
Option Locking - Prevent your users from changing certain options in Indigo Backup.
Automatic Updates - Centralised updates for your users Indigo Backup system
Initial Indigo Setup - Set the basic features up automatically for each user upon install.
Email Remote Administration - Have Indigo Grid email you each scan so that you can keep up-to-date with your backup system from anyware in the world.


Example Architecture (A)

 

   
 

Example Architecture (A)


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 (B)

 

   
 

Example Architecture (B)


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

© Copyright 2005 Indigo Prime