Restoring from a Back-up
In the unlikely event that your database becomes damaged, you will need to attempt to recreate it. As part of this process, you should revert to a
text back-up or
database copy, and begin to use it as quickly as possible, to keep the interruption to your company's daily work to a minimum. Also as part of this process, you should attempt to recover any data that was entered to the damaged database after the text back-up or database duplicate was created.
If you are using journaling, please refer to this page for details about how to proceed. Using journaling will allow you to create a new "live" database much more quickly than the method described below. If you are not using journaling, the recommended course of action is as follows:
- Revert to the most recent undamaged text back-up or database duplicate, as follows:
- If you are able to revert to a database duplicate, simply copy the duplicate into the folder containing the Standard ERP server application and rename it to "HANSA.HDB". Log in to check that the duplicate is undamaged.
- If you need to revert to a text back-up, follow the procedure described later on this page. In large systems, reverting to a text back-up will take some time.
- The database that results from step 1 will become your "live" database. You should now make room in this database for the recent data that you will recover from the damaged database.
Open all relevant Number Series settings and in each case create a new number sequence that leaves a large gap after the last used number. In the case of Contacts and Items, you can do this in the Number Series Defaults setting in the System module.
- Allow users to log in to the database and to start work, but ensure they only carry out the most essential tasks. You may feel the need to restrict access to the less frequently used tasks using Access Groups.
- You can now attempt to recreate any data that was entered to the damaged database after the last database duplicate or text back-up was made. This may require you to attempt to create a Database Text Back-up or Raw Data export file from the damaged database. Then, import the information in this file to a test database. Find the recently entered data in this test database and export it using the relevant Export routine in the Integration module. The Transaction Registers Export will be particularly useful, as it allows you to export a specified range of records from every Sub System. Finally, import this data to the database created in step 1 (the new "live" database). The Raw Data feature is described here, while using the Export routines is described here.
If you are unable to create a Database Text Back-up or Raw Data export from the damaged database, you will need to refer to any paper records and to enter the data manually to the new "live" database.
The importance of documenting in detail each step in the recovery process cannot be emphasised strongly enough. As you recreate your data, keeping detailed records will allow you to be sure of exactly what has and has not been recovered at all times. These records will also allow you to account to the legal authorities for gaps in the Invoice Number and other number sequences following step 2.
Note that if you are using journaling, applying the journal to the most recent database duplicate will be a much faster and more certain method of recreating the data that was entered to the damaged database after the last database duplicate or text back-up was made. You will therefore not need to run both "live" and test systems side-by-side as described in steps 2-4 above, unless you feel the need to ascertain that you have recreated all the data.
We will now describe in detail how to restore a database from a text back-up file, as mentioned in step 1ii above. For reasons of speed, it is recommended that you carry out the process of restoring from a back-up on the server machine in multi-user systems, using the command line (Linux or Mac OS X) or service (Windows) application. If this is not possible, use a single client machine and then copy the database file (named "HANSA.HDB") to the server. If you have separate back-up files for different Companies, they should be imported individually. Attempting to import them simultaneously using different client machines could result in data being lost.
Restoring from a back-up is done in the following way:
- Move the old database (named "HANSA.HDB") away from the folder or directory containing the Standard ERP application. Rename it so that you know what it contains.
- Delete the database file "HANSA.HDB" from the folder or directory containing your Standard ERP application. Double-clicking the application now will force it to create a new database, as described here.
! | It is important to restore to a new, empty database, to avoid mixing the restored data with the old, damaged database. |
|
The "DBDEF.TXT" and "DEFAULT.TXT" files should always be present in the same directory/folder as the Standard ERP application. They contain some important data used when setting up the new database and creating new Companies. If these files are missing, your Standard ERP application may not work the way you expect it to do!
- It is recommended for reasons of speed that you use the command line or service application to import the text back-up file. Proceed to step 9 below. If this is not possible, launch the GUI Standard ERP application as normal. When the 'Welcome to Standard ERP' window appears, click the [Import Textbackup] button:
- The 'Import files available' window opens. This is a list of text back-up files. To be included in this list, a text back-up file must be stored in the folder or directory containing the Standard ERP application or in the "Backup" or "Setup" folders inside that folder. It must also have a .txt extension.
In the list, the filename of each text back-up file is shown together with the date it was saved and any description added when it was created (see step 4 on this page).
- Highlight the file you want to import (the back-up to which you wish to revert) and press the Enter key (or double-click on the name of the file). The back-up data will be imported.
If your back-up file is not shown in the list of available files because it is not stored in the "Backup" or "Setup" folder or directory (or because its name does not have a .txt extension), continue with these steps:
- Click the [Select File Manually] button in the top left-hand corner of the 'Import files available' window.
- When the 'Open File' dialogue box opens, locate and open the back-up file in the normal way.
The back-up data will be imported.
- If you are working on a Linux or Mac OS X server using the command line application, launch the application by typing:
- ./StandardERPServer Backup/TBXXXXXX.TXT (Linux 32-bit),
- ./StandardERPServer64 Backup/TBXXXXXX.TXT (Linux 64-bit) or
- ./StandardERPServer Backup/TBXXXXXX.TXT (Mac OS X)
- Starts the Standard ERP server application and imports the back-up or example data file TBXXXXXX.TXT. In this example, this file is in the "Backup" folder inside the folder containing the Standard ERP server application.
The progress of the import will be shown in the Terminal window. Standard ERP will quit when the import finishes. Restart it by typing:
- ./StandardERPServer (Linux 32-bit),
- ./StandardERPServer64 (Linux 64-bit) or
- ./StandardERPServer (Mac OS X)
If you are using the service application (Windows), place the path and name of the back-up file (Backup/TBXXXXXX.TXT in this example) in a "parameters.txt" file before launching the application, as described in the 'Launching the Server with Parameters' section on the Loading an Existing Database and Company page. The application will quit when the import finishes (you may need to monitor the log file (named "hansa.log") or the service 'Properties' window to see when the application quits). Remove the path and name of the back-up file from the "parameters.txt" file. Then, restart the service application in the usual way. An alternative to using the parameters.txt file is to drag and drop the backup file onto the service application. The application will again quit when the import finishes. You can also use the GUI application to import a text back-up file as described in steps 1-8 above.
If your machine has sufficient RAM, the back-up file will be imported significantly more quickly if you use the "Massive Cache" feature to increase the size of the memory cache. You can do this by placing an extra parameter in the command line or in the "parameters.txt" file, as follows:
- ./StandardERPServer --db-cache=1G Backup/TBXXXXXX.TXT
The "1G" will create a 1 GB massive cache. You can set the massive cache size using K, M (not MB) or G (not GB). Make sure the parameter does not contain any spaces.
By default, the Standard ERP server application uses a cache size of 12 MB. By increasing the size of this cache, you will improve the speed of operation because data that is in the cache can be accessed much more quickly than data on disk. Data in the cache is data that has already been used during the work session. The optimum size of the cache will vary, depending on the server type, RAM size and operating system, and can only be established through experimentation. A good guideline, especially for Windows servers and for servers with smaller RAM sizes, is never to assign more than 40% of the machine's RAM size to the cache. If the cache is too large, the memory available for other tasks may not be enough. If the machine then runs out of memory, it will start using its hard disk as extra memory. This will cause it to slow down significantly and may also increase instability. If the server is a 32-bit machine, the maximum cache size is between 1 and 3.5 GB, depending on machine and operating system. If the server is a 64-bit machine with a 64-bit capable operating system (Mac OS X or Linux) and a large amount of RAM and if you are using the 64-bit version of Standard ERP, then the 40% guideline becomes less important. For example, if the server has 12 GB RAM, you could assign up to 10 GB to the cache.
If you do increase the cache size significantly, there will be a pause between the import finishing and the application closing. During this time, the cache contents will be written to disk. The larger the cache, the longer this will take.
---
In this chapter:
Go back to: