Why mention automated backups as a reason for using ICommander on a Redhat Linux
Server?
Because of too many experiences with undependable backups. ICommander Corporation has always emphasized the importance of backing up data files that cannot be replaced from anywhere besides your backups. Installation and training always stress the importance of this and one section of the ICommander Manual is devoted to it. We also stress the importance of regularly putting a copy of the backup offsite in case of a fire or other disaster.
At one point many of our customers were using various Windows systems either for their main operations or at remote sites (before we developed a way for remote sites to securely use the central office Redhat Linux Server via the Internet). We experienced some cases when there was a need to restore some files from the backups that the backups did not exist or were not usable. This was due in part to varying software and media used for backups.
Sometimes the media needed to be formatted or prior backup data deleted in order to reuse a disk or tape and this was not being done. In other cases the backup device had gone bad at some point and no one knew. Other times someone working with the Windows System who was unaware of the significance of the accounting data had changed the scheduled backup so other areas were included but not the accounting data.
We also found it was not unusual when the backup device was changed that no one setup the new device to automatically do the backups. We also found instances related to backup device changes where mistakes were made in setting what was to be backed up and the success of the backups had never been tested.
We also found it was highly unusual for users to be familiar with how to restore files from their backup and that they had never tested that they could successfully do it.
Our implementation of ICommander Redhat Linux Servers requires a high-quality very dependable backup medium. This has sometime meant a comparatively expensive device and media but we refuse to support a system where we are not satisfied with the reliability of backups.
Since the typical ICommander Redhat Linux Server is dedicated to running ICommander on the network, ICommander Support Staff is able to structure the nightly backups and other tasks to include all locations where data is stored plus other critical directories. This includes provision of the Linux scripts that actually do the backups and managing the cron task manager that Linux and Unix use for recurring scheduled tasks.
All backup scripts use error checking and create a log of every file that was to be backed up and another that shows every file that was backed up. The log files can be very long so we show our customers how to use some Linux tools to quickly check that the backup completed successfully. We insist on that being done at the point that one tape is taken out and another put in. We keep separate log files for each day of the week and other separate logs for any special purpose or manually invoked backups. The logs themselves also include guidance on how to restore files so there is no time lost in researching that when it needs to be done.
Customers are requested to immediately contact ICommander Support in the event that a backup log indicates a failed or incomplete backup. ICommander Support Staff is also instructed to review the log files when they have occasion to work on a customer server and to verify that someone is regularly reviewing. If new areas need to be backed up (such as when we implement use of the Apache Web Server for an ICommander Intranet), ICommander Support Staff will update the backup scripts to include any new areas that need to be backed up.
We also strive to have customers use tape drives that are compatible with one of
the ICommander Corporation Linux Servers. This is to allow for a disaster where
a system must be replaced. Temporary use of one of our servers that allows
remote access then is a simple way to get the customer back in operation until
a new system is in place.