Ferro Backup System - The best Backup Software
Network Backup & Restore Software Solution for SMBs
  EN    PL    ES   

Article ref. no : FS-FBS-20101201-I01
Last revised : 3 December 2014
Version: 1.1

Administering the backup system - most common mistakes made by backup operators and ways to avoid them

This article presents the most common mistakes committed by backup operators which can potentially lead to loss or damage of backup data. It contains a number of tips for remedying problems and avoiding difficulties during restore.


In the article “Optimum backup scope patterns” we provided information useful in configuring backup tasks. Fast, efficient and fully automated backups are essential, but is that all there is? To feel secure, a user also needs to protect the backup copies themselves. Losing valuable information most often comes as a surprise, and one that is not pleasant. However, what can be even more surprising and unpleasant is when we think we have a backup copy, but in fact we do not, or it has been damaged. There could be many causes of a backup copy being lost. As in the case of a loss of data, the most frequent causes include: human error, hardware failure, software errors. User error resulting in a loss of backed-up data would most likely involve unsuitable media storage, or an incorrectly configured backup system or security software. Such errors may cause backups to be lost at a later time, even though at first everything seems normal. See below for the most common administrator errors.

Backup server location

It is a basic rule of data security that backup copies should be stored in a different location than the original data. In the case of disk-to-disk backup systems, including Ferro Backup System, the main storage is on a hard disk or on a disk array, often built into the backup server. The backup server should thus be stored at a location different than the data subject to backup. In many small companies and institutions, this is often difficult because of the significant cost involved. What to do, then, if it is not possible to place the backup server in another building? In such a case, backup replication is a good solution.

Backup replication

Ferro Backup System supports automatic or periodic (based on a set schedule) duplication of backup copies to another network location (NAS, FTP server, etc.), external hard disk, optical drive (CD/DVD/Blu-ray/HD-DVD) or tape drive (DDS, DLT, LTO, AIT, etc.). The most convenient replication method is replication over a wide area network to a server or a network drive. The most common limitation with such a method, however, is bandwidth, which may not be sufficient to transfer backup copies of hundreds of gigabytes. Therefore, when using a slow connection, the operator may choose to replicate only the most crucial information. Data which is crucial to the organization should be relegated to a separate backup task, and only those backups should be replicated over the WAN. Naturally, if a fast network connection is available, it might be a good solution to replicate all backups. Another method of replicating data is to copy it to an external hard disk drive, CD/DVD/Blu-ray disk, or tape. In such a case, remember to have at least two media of the selected kind. One medium should be placed in the drive in the backup server and the other should be stored outside the company premises, possibly in a safe. Media on which copies of backups are stored may of course be periodically swapped: secure the most recent medium and replace the medium previously stored in a different location in the backup server’s drive.

Backup versioning, or how many copies back should be stored?

Another backup configuration error involves incorrect setting of the backup versioning option. Setting the "Rotation backups" (backup versioning) value too high may cause all storage space on the disk to soon run out. Setting it too low, however, may mean that when the user realizes that some data (files) have been deleted it will be too late, because the versioning mechanism has already removed the backup copies of such files. It is good practice to split one large backup task into several smaller ones. For example: a backup of the whole system, usually large, can be scheduled as a less frequent task. Critical files and documents may, however, be backed up as part of a different task, which due to its smaller size may be run more often (e.g. daily). This means that the “Rotation backups” value can be higher without the risk of running out of disk space on.

Disk folder privileges

Another issue which may “accidentally” come up at a later stage is changing folder privileges. By default, the backup agent (FBS Worker) operates in the System account. If for some reason the user restricts that account from accessing folders, the backup software will not be able to complete its work because of folder access denial by the operating system. It is good practice to directly specify the names of important files or folders when setting the backup scope. FBS will then immediately display a warning if a selected path is inaccessible.

Automatic updates of security software

Another type of problem which may be encountered later on, through no direct fault of the administrator, is the functioning of other software. For instance, immediately after installing the backup system, the administrator configures the antivirus software and firewalls. Tests come up positive and everything is working fine. However, security programs feature automatic update functionalities. Updating a program or its security definitions may cause the backup system to be aborted or restricted in its operations. In such situations, there will most often be problems connecting clients to the backup server or, less frequently, backups which have already been saved may become damaged.

Lost connections from workstations may be monitored from the FBS Server in the Backup | Tasks tab, where any possible backup process delay will be shown in the Delta column. A delay of several days might mean the connection has been lost. This can also be monitored in the following reports: Delayed tasks and Last task.

After the backup is completed, the server will automatically verify the integrity of the backup copy. However, faulty operation of antivirus software on a backup server may cause older backup copies to become damaged as well. One should always remember to properly configure the antivirus program by excluding backup folders or Ferro Backup System processes. Every now and then, one should also perform a test restore or schedule an automated periodic backup verification.

Incorrect scope of backup

Another common mistake is incorrect backup scope without excluding temporary folders. After a while, this may prolong backup time several times and cause backup sizes to swell gradually. If information from tens or hundreds of workstations is backed up, due to a gradually increasing amount of (unnecessarily) backed-up data, the backup operation may not be completed in the time scheduled, or the medium on the backup server may run out of space. Therefore, it is necessary to think carefully about the scope of the backup and to exclude files and folders which are not essential to restore. Failure to exclude temporary files may cause another problem – too many file access warnings being generated.

No supervision due to too many events

It is worth mentioning another very common mistake, that of neglecting to periodically monitor the operation of the backup system because of too many warnings and errors being displayed. If the backup system has been reporting a problem for a long time and the administrator fails to react in a timely manner, this may cause the backup to be lost. Ignoring warnings is mostly caused by incorrect software configuration where, every day, hundreds of new and repeating exceptions are registered in the Event Log, which makes subsequent analysis of software operation difficult. Backup tasks should be configured so that no errors or warnings are generated on a daily basis. Otherwise, the operator will not spot the exceptions which may later affect the restorability of the backup copy.

Backup server monitoring

There are several situations where FBS Server may be stopped. If, for example, the server cannot access the disk on which it stores backup copies, it will stop and an error entry will be made in the event log. To make sure the operator is notified in due time of the fact that the server has stopped, use the Administrative alerts available in the software. Thanks to daily emails detailing any new errors and warnings, the operator may react in a timely manner. If the alert is not delivered in due time, it may indicate that the program or the operating system has crashed or that there is a fault in the computer, which should also put us on our guard.

A busy operator may, however, overlook the fact that an alert email has not arrived. It is therefore more reliable to use network monitoring tools, e.g. the popular UNIX/Linux and Windows solution – Nagios. The backup server may be automatically monitored in several different ways:
  • by sending an echo request (ping),
  • by checking whether FBSServer.exe process is running,
  • by attempting to connect using the TCP 4531 port.
The last method is the most reliable one. If FBS Server accepts incoming connections, it means that the integrated TCP server, the FBS Server software and the computer are all working.


Performing automatic backups using appropriate tools is essential. This, however, does not relieve administrators of their duty to verify whether the backup system, once installed and configured, is still performing as in the beginning. By following the principles of correct media storage, backup replication, log error checking or backup server monitoring, the operator can prevent situations where it would be impossible to restore lost data from a backup copy.

See also

Home   Help   Where to Buy    Download    Contact Us   Partners   |  Printable version  |  Language: EN EN   PL PL

Network Backup System Administartion
All rights reserved.
Copyright © 2000-2022 FERRO Software