Enabler Backup and Restore
Created: 31 July 2009. Last Reviewed: 07 October 2014
Automated Backup and Restore System
A system for automatically creating backups on databases and configurations has been created. There is a corresponding function to restore these backups on demand, or else they may be restored manually via the command prompt.
The automatic creation of backups is controlled via a new configuration screen:
Specify the full path to the directory where backup files should be created. This may be a network path as shown above, or a local disk drive – e.g. e:\ or e:\backups.
Days to retain backups
Enter the number of days to retain each backup. Any backups older than this setting will be deleted prior to creating the latest backup.
Backup configurations (local)
Local configuration files (*.ini from the enabler root directory (normally \enabler) will be added to the backup.
Backup configurations (central)
The central configuration database will be backed up. This means that all files and subdirectories under the the central configuration path (normally \enabler\comms\config) will be added to the backup.
Backup lan transaction database
- .dbf from the LANTRAN database directory will be added to the backup.
Backup local database
- .dbf from the LOCAL database directory will be added to the backup.
Backup lan maintenance database
- .* from the LANMNT directory and all sub-directories will be added to the backup. Note that this means the .PRM files from the isl-bu directory will also be included.
Backup electronic journals
- .jnl from the LANTRAN\journals directory will be added to the backup.
What Machines Should I Backup?
Generally, backup the store servers and head office server. There is probably little advantage to be gained by running backups on store nodes (AKA tills) as these data are general recoverable from the store server anyway.
What Files Should I Backup?
On a store server, generally all configurations and LOCAL database contents can be recovered from the HO server if necessary, so there is an argument for not backing these up. However, if disk space and over-night window of opportunity permit (see below), maintaining backups of these in stores may be useful. It is probably more convenient to recover from an in-store backup than from HO, should recovery be necessary. Also, in some cases the product file may differ in each store, particularly if using the range file option in Enabler or stores having different prices controlled by EEE.
Where Should I Backup To?
In a multi-till installation, it is useful to save backups on the hard disk of a different machine in the store. For example, if backing up data from the store server, specify till 2 as the backup location: \\xx_010102\en\backups\server.
In a single-till installation. If a ZIP or JAZ drive or other removable media drive is available, write backups to this drive. Either use the root directory or some sub-directory. Note – any directories specified will be created by the backup process if they do not already exist. If no removable media drive is available, there may still be merit in backing up to the local hard disk. While this provides no protection against disk crashes, it may provide protection against general file corruption or corruption or data-loss caused by application errors or inappropriate user intervention.
When Does The Backup Happen?
The backup is run overnight, as part of the scheduled data purge process. Note: If the data purge is not scheduled to run, the backup will not happen!! Accordingly, the data purge event has been renamed to “Purge & Backup” in the schedule setup screen.
Reasoning Behind This Approach:
The backup needs to occur overnight, and needs to happen automatically.
The backup needs to be run after EOD and before Resume – normally the data purge is configured to run between these two events.
It is often desirable that EOD completes quickly, for example to produce EOD files to be collected by comms. So it is not appropriate to add a lengthy process such as a backup to the EOD. The backup runs just before the actual data purge. So, if the data purge is scheduled for 2:00am, the backup runs at 2:00am and the purge runs immediately upon completion of the backup. Running the backup before the data purge means that we have a backup in the event that the data purge leads to corruption – e.g. purge parameters set incorrectly so that data is inadvertently deleted.
It is better to not create a separate scheduled event for the backup. This would require timing buffers, which effectively means that the overnight processing requires more time overall to complete. For example, if the backup was to be scheduled separately at 3:00am, you might have to wait until 4:00am to start the purge, just to be sure that the backup was complete – even though the backup might take only 20 minutes. By combining these two events we make optimum use of the window of opportunity to perform these housekeeping tasks.
Entries are written in the event log showing the start and end time of the backup process. Additional entries are created if errors occur during the backup.
Where/How are the Backups Stored?
The backups are stored in standard .ZIP files in the path specified in the configuration screen. The zip file name is the date of creation in CCYYMMDD format. So, a backup created at 2:00am on 21 March, 2002 would be named 20020321.ZIP.
Inside the zip file, all backed up files include the full original disk path. E.g. enabler/lantran/posdsale.dbf. However, the local configuration files are an exception – these are stored in the root of the backup ZIP file.
Backups may be restored manually using tools such as Winzip or PKUnzip (on the infoctrl.exe decompress command line).
Backups may also be stores using the Restore option on the Back Office file menu:
Using the Back Office file menu requires that all other Enabler applications, including Nibbler, first be closed. If other applications are found to be running, a message will be displayed reminding the operator to close other applications. The restore will not be able to proceed until the other applications are closed. If the Nibbler monitor is running within Back Office, Back Office will automatically suspend the monitor during the restore process, and resume the monitor when the restore is complete.
Upon selecting File/Restore Backup, the Restore Backup screen (below) is displayed:
Select which backup file to restore data from in the list of the left hand side. This will list all .ZIP files found in the configured backup path. Select which parts of the backup should be restored using the check boxes on the right. Click Restore and confirm to proceed.
Note – the restore option will automatically overwrite any files that already exist – this is necessary and desirable if you are running the restore in order to recover from corruption. However, use with care as it is possible to overwrite good data with out-of-date data from the backup!
If LOCAL or LANTRAN databases are restored, the restore process automatically invokes a reindex on the restored database once the .DBF files have been recovered.
What if I Restore Databases Backed Up Under an Older Enabler Version?
If you restore a database that was backed up from Enabler version 4.xx and you are now running Enabler version 4.xx+y (where y > 0), you would need to manually run a database migration to bring the databases up to date.
When to Restore Using Menu Option as Opposed to Manually
The menu option provides a convenient way to recover an entire backup, or large portions of a backup, but it is not always appropriate to use the menu option:
The menu option does not provide great granularity – you can either restore the entire LOCAL database, for example, or none of it. If you need to recover only a single file, it would be necessary to recovery manually using pkunzip or winzip. You would need to reindex the file(s) recovered using this process. If Enabler data or configuration is badly corrupted, it might not be possible to launch Back Office. Therefore, you would need to recover manually using pkunzip or winzip. If you want to try restore a backup, just to see if it fixes a problem, you should probably manually backup the configurations/data that you are about to overwrite from the backup. If restoring doesn’t work, you probably want to revert to the most recent data – remember, the backup is only up to date as at last night (at best)!!!