Återställa efter en 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. 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 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.
- If you are able to revert to a database duplicate, simply copy the duplicate into the folder containing the HansaWorld Enterprise server application and rename it to "HANSA.HDB". Log in to check that the duplicate is undamaged.
- 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 text back-up or database duplicate 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 text back-up or database duplicate 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 1i 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 HansaWorld Enterprise application. Rename it so that you know what it contains.
- Delete the database file "HANSA.HDB" from the folder or directory containing your HansaWorld Enterprise 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 HansaWorld Enterprise application. They contain some important data used when setting up the new database and creating new Companies. If these files are missing, your HansaWorld Enterprise 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 10 below. If this is not possible, launch the GUI HansaWorld Enterprise application as normal. When the 'Welcome to HansaWorld' 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 HansaWorld Enterprise 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:
- If it is still open, close the list of available import files using the close box.
- The 'Select Company' window is shown: double-click the top line in the list (marked "1"), or press the Return or Enter key.
- When the Master Control panel opens, change to the System module and use the Ctrl-Shift-I/⌘-Shift-I keyboard shortcut to open the 'Imports' window:
- Select 'Automatic, manual file search' and press the Enter key (or double-click on 'Automatic, manual file search').
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:
- ./HansaWorld Backup/TBXXXXXX.TXT &
- Starts the HansaWorld Enterprise 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 HansaWorld Enterprise server application.
The progress of the import will be shown in the Terminal window. When it has finished, HansaWorld Enterprise will quit. Restart it by typing:
- ./HansaWorld &
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. When the import finishes, the application will quit (you may need to monitor the log file (named "hansa.log") to see when the application quits). Remove the path and name of the back-up file from the "parameters.txt" file and then restart the application in the usual way. Alternatively, use the GUI application to import a text back-up file as described in steps 1-9 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:
- ./HansaWorld --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 HansaWorld Enterprise server application uses a cache size of 3.2 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 HansaWorld Enterprise, 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:
