Enabler Backup and Restore: Difference between revisions

From EnablerWiki
Jump to navigationJump to search
No edit summary
Brant (talk | contribs)
No edit summary
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
Created: 31 July 2009. Last Reviewed: 31 July 2009
Created: 31 July 2009. Last Reviewed: 07 October 2014


Enabler has Backup and Restore functionality built in to assist with scheduling backups of Enabler data and restoring Enabler data in the case of database corruption or Hardware failure.  This Backup and Restore functionality should be used to backup the Enabler data, rather than backing up the data directly using 3rd party applications.  If using a 3rd party solution potential issues can arise with Database File locking and other corruption.
====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.
=====Backups=====
The automatic creation of backups is controlled via a new configuration screen:
   
[[File:Backup-1.jpg|500x250px]]


===Enabler Backups===
[[File:Backup-2.jpg|The backup configuration screen is illustrated above.|400x200px]]
When using the Enabler Backup functionality, the backup selections are copied to a compressed zip file in the specified path. This file can then be backed up as part of a 3rd party backup to removable media such as tape. 
======Backup Path======
 
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.
====Configuration====
Various configuration options are available for the Backup system.  It is recommended that different backup scenarios be configured for Store Servers (including the Head Office Server) and Tills.  This is to avoid conflicts with different tills trying to backup the information on the store server at the same time. If this occurs, there is the potential for database locking errors to occur and cause further damage to data. 
 
=====Store Server configuration=====
Back Office ⇒ Local Store Setup ⇒ Transaction Processing/Comms ⇒ Backup Options Setup ⇒ Select ‘Store Server’ only ⇒ enable ‘Create backups’
 
[[Image:Enabler_Backups_Figure1.JPG]]
 
======Backup path======
Specify the full path to the directory where backup files should be created.  This may be a local path as configured in Figure 1, or it can be a UNC network path (EG. \\till02\ebackups)
======Days to retain backups======
======Days to retain backups======
Specify the number of days to retain each backup file.  Any backup files older than this setting will be deleted prior to creating the latest backup.
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)======
======Backup configurations (local)======
Local configuration files (*.ini files located in the Enabler root directory (usually \Enabler) will be added to the backup
Local configuration files (*.ini from the enabler root directory (normally \enabler) will be added to the backup.
======Backup configurations (central)======
======Backup configurations (central)======
The central configuration database will be backed up.  This means that all files and subdirectories under the central configuration path (normally \Enabler\Comms\Config) will be added to the backup
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======
======Backup lan transaction database======
All *.dbf files from the LANTRAN database directory will be added to the backup.
*.dbf from the LANTRAN database directory will be added to the backup.
======Backup local database======
======Backup local database======
All *.dbf files from the LOCAL database directory will be added to the backup.
*.dbf from the LOCAL database directory will be added to the backup.
======Backup LAN maintenance database======
======Backup lan maintenance database======
All files 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.
*.* 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======
======Backup electronic journals======
All .jnl from the LANTRAN\journals directory will be added to the backup.
*.jnl from the LANTRAN\journals directory will be added to the backup.
 
=====Store Till configuration=====
Back Office ⇒ Local Store Setup ⇒ Transaction Processing/Comms ⇒ Backup Options Setup ⇒ Select ‘Tills’ only ⇒ enable ‘Create backups’


[[Image:Enabler_Backups_Figure2.JPG]]


It is recommended that only the Local Enabler data be backed up on a Till.  This ensures there will be no Database Locking issues if the till attempted to backup the transactional databases at the same time as the store server. 
=====Backup Strategies=====


====Backup Strategies====
======What Machines Should I 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.   
All Store Servers and the Head Office Server should be configured to Backup using the Enabler Backup functionality.  <br />
======What Files Should I Backup?======
Although it is not important to backup tills (as there is no transactional data kept on the tills), it can be advantageous to backup the local databases so that any issues that may occur on the till can be traced back via the <rrbbtt>b.dbf Nibbler Backup File.   
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?=====
======Where Should I Backup To?======
It is an advantage to backup to a location other than the local Hard Drive.  Backing up to another location helps to avoid full data loss if the Hard Drive fails.   
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.
======Network Location======
<br/><br/>
As mentioned, the backup path can be set as a network location using a UNC path.  A Store Server could be configured to backup to a Till, and the Till configured to backup to the Store Server.  <br />
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.
EG:  Store Server backup path:  \\Till01\enbackups\ <br />
=====When Does The Backup Happen?=====
Till backup path:  \\Server01\enbackups\
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.   
======Removable Drive======
======Reasoning Behind This Approach:======
Removable USB or Zip drives are ideal for single-till installations (where only a store server is used).  USB Drives are cheap, reliable and have more than enough space to hold the backup data.  They can also be easily swapped each day and taken away offsite for extra protection.  These devices usually display as a local drive.  <br />
The backup needs to occur overnight, and needs to happen automatically.<br/>
EG: Backup Path:  E:\enablerbackups
The backup needs to be run after EOD and before Resume – normally the data purge is configured to run between these two events.<br/>
======Local Hard Drive======
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.
If no other location is available, there is still merit in backing up to the local hard drive.  While this provides no protection against drive failure, it can provide protection against general file corruption or data loss caused by application errors or inappropriate user intervention.  <br />
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.<br/>
EG: Backup Path:  C:\Enabler\backups
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.


=====How are the Backups stored?=====
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.
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.  <br />
Inside the zip file, all backed up files include the full original disk path.  EG: Enabler\Lantran\posdsale.dbf.  However, the local configuration files are an exception – these are stored in the root of the backup ZIP file.


====Backup Scheduling====
=====Where/How are the Backups Stored?=====
The backup is run as part of the Data Purge process.  If this is not scheduled to run, then the backup will NOT occur.  The reason behind this approach is that the Backup generally needs to occur overnight, it needs to happen automatically and it needs to be run after the End of Day but before the Till Resume scheduled events.  Normally, the Data Purge is configured to occur between these two events.  <br />
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.
It is better not to 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 Enabler makes optimum use of the window of opportunity to perform these housekeeping tasks. <br />
The backup will run just before the actual data purge.  EG:  If the Purge and Backup is scheduled for 02:00am, the backup will run at 02:00am and the purge will run immediately on completion of the backup.  Running the backup before the purge means that a backup is available in the event that the data purge leads to corruption, or a purge parameter is set incorrectly so data is inadvertently deleted.  <br />
Back Office &rArr; Local Store Setup &rArr; Transaction Processing/Comms &rArr; Scheduler Setup &rArr; Enable ‘Purge & Backup’


[[Image:Enabler_Backups_Figure3.JPG]]
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.


To enable Purge and Backup you can configure it to run immediately after the End of Day (as in Figure 3), or you can manually specify a time for it to run.  <br />
=====Restoring Backups=====
'''''Note:''''' 
Backups may be restored manually using tools such as Winzip or PKUnzip (on the infoctrl.exe decompress command line).   
''As previously mentioned, this task should be run after the End of Day, but before the Resume Till. It is also recommended that it is scheduled to avoid conflicting with the other tasks, Host Import and Forward Pricing.  ''


Backups may also be stores using the Restore option on the Back Office file menu:


================================
[[File:Restore-1.jpg|800x600px]]
To guard against data loss, the Enabler backup option should be configured to backup the Enabler store server to either another machine on the network, or to a USB drive attached to the store server.


Enabler backups are configured from Local Store Setup-> Transaction Processing / Comms-> Backup Options Setup. The following options can be set when “Create Backups” is turned on.
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:


* Backup pathFull path of backup
[[File:Restore-2.jpg|400x200px]]
* Days to retain backupsDays before backups are overwritten
* Backup configurations (Local)Configurations for store server
* Backup configurations (Central)Configurations for all store machines
* Backup Lan transactions databaseLANTRAN databases
* Backup local databaseLOCAL databases
* Backup lan maintenance databaseLANMNT databases
* Backup electronic journalsJournal files (\Enabler\Lantran\Journals)


Whilst backups can be performed to the same drive that Enabler is stored on, this only guards against data corruption and not hard disk failure. That is why it is recommended that backups be performed to a drive external to the Store server (USB, NAS, shared drive).
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!


For the backups to run after “Create Backups” has been turned on, you need to have “Purge & Backup” configured in Scheduler Setup.
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.


Whilst it is not necessary to backups tills, as all transactional data and till configs are held on the store server, if you did wish to backup tills, you would only turn on:-
=====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:


* Backup configurations (Local)
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.
* Backup local database
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)!!!

Latest revision as of 04:42, 7 October 2014

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.

Backups

The automatic creation of backups is controlled via a new configuration screen:

The backup configuration screen is illustrated above.

Backup Path

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.


Backup Strategies
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.

Restoring Backups

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)!!!