Enabler Backup and Restore: Difference between revisions

From EnablerWiki
Jump to navigationJump to search
Add Restore details to page
Brant (talk | contribs)
No edit summary
 
Line 1: Line 1:
Created: 31 July 2009. Last Reviewed: 16 February 2011
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:
[[File:Backup-1.jpg|500x250px]]


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. 
[[File:Backup-2.jpg|The backup configuration screen is illustrated above.|400x200px]]
 
======Backup Path======
===Enabler Backups===
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.
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. 
 
====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]]
=====Backup Strategies=====


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.   
======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.
<br/><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.
=====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.<br/>
The backup needs to be run after EOD and before Resume – normally the data purge is configured to run between these two events.<br/>
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.<br/>
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.


====Backup Strategies====
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.
=====What Machines should I Backup?=====
All Store Servers and the Head Office Server should be configured to Backup using the Enabler Backup functionality.  <br />
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. 
=====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. 
======Network Location======
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 />
* EG:  <br />
Store Server backup path:  \\Till01\enbackups\  <br />
Till backup path:  \\Server01\enbackups\
======Removable Drive======
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 />
* EG: Backup Path:  E:\enablerbackups
======Local Hard Drive======
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 />
* EG: Backup Path:  C:\Enabler\backups


=====How are the Backups stored?=====
=====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. <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.
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====
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.
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 />


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 />
=====Restoring Backups=====
Backups may be restored manually using tools such as Winzip or PKUnzip (on the infoctrl.exe decompress command line).   


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 />
Backups may also be stores using the Restore option on the Back Office file menu:
* Back Office &rArr; Local Store Setup &rArr; Transaction Processing/Comms &rArr; Scheduler Setup &rArr; Enable ‘Purge & Backup’


[[Image:Enabler_Backups_Figure3.JPG]]
[[File:Restore-1.jpg|800x600px]]


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 />
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.
'''''Note:''''' 
* ''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.  ''
 
===Restoring Backups===
If a situation arises where backups must be restored, it is recommended that the operation is discussed with Magenta Support prior to proceeding with the steps below.  This is to ensure the correct procedure is used and to avoid overwriting/deleting data. 
====Assisted Restore====
Backups can be restored using the ‘Restore Backup’ option on File menu in the Back Office. 
* Back Office &rArr; File &rArr; Restore Backup <br />
'''''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!''
 
Using the Restore Backup option requires that all Enabler applications are first closed.  This includes Nibbler and POS.  If other applications are found to be running, a message will be displayed advising them to be closed.   
 
If Back Office is monitoring Nibbler, Back Office will automatically suspend Nibbler for the duration of the restore and will resume Nibbler when the restore is complete. 
 
Upon selecting the Restore Backup option in Back Office, the Restore Backup window is displayed (Figure 4).
 
[[Image:Enabler_Backups_Figure4.JPG]]
 
The list of backup files will show all .ZIP files that are located in the configured Backup Path.
Select the backup file to restore data from and select the components to restore from that backup file.  Click Restore to proceed.
 
If LOCAL or LANTRAN databases are restored, the restore process automatically invokes a re-index on the restored databases once the .DBF files have been recovered.


====Manual Restore====
Upon selecting File/Restore Backup, the Restore Backup screen (below) is displayed:
The Assisted Restore menu option provides a convenient way to recover an entire backup, or large portions of a backup, however it doesn’t provide a great level of granularity.  EG:  You can restore the entire Local Database, or none of it.  You could not restore single files from within the backup files.  If Enabler data or configuration is badly corrupted, it might not be possible to launch Back Office. Therefore, you would need to recover manually


Files within the backup files may be restored manually using Windows Explorer (Windows XP and above) or tools such as Winzip or PKUnzip. Individual files can be restored to their original locations or copied elsewhere. 
[[File:Restore-2.jpg|400x200px]]


Using the Manual Restore scenario requires that all Enabler applications are first closed.  This includes Nibbler, POS and Back Office. If any of the applications are open, the restore may fail.
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:''''' 
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 you manually restore a database .DBF file, you must re-index the recovered files before starting any Enabler application.  This process also requires that all Enabler applications are first closed.''


* ''If you want to try to restore a backup, just to see if it fixes a problem, you should manually backup the configurations/data that you are about to overwrite from the backup. If restoring the data doesn’t resolve the problem, you should back revert to the most recent data i.e before the restore – remember, the backup is only up to date as at last night (at best)!!!''
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.


====Restore to a different Enabler version====
=====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.  
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.  


This can be done using the following command from within the Enabler folder at the Windows command prompt:
=====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:


C:\Enabler> INFOCTRL MIGRATE
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)!!!

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