Scheduling a backup ensures that there is always a copy of your work separated from the main data files. Manual backups allow for incidental backups to be done, and the folder structure ensures they are in different locations. These backups can be used for restoring in an emergency, or to prepare a training database.
 |
The Jim2 database is re-indexed each time a backup is performed. |
The Jim2 Server Console screen has a number of backup options.
Backup
Field |
Explanation |
Database |
Choose the working database you wish to back up. |
File Name |
Give your backup file a name. |
Backup to |
Select the destination of the backup files, ensuring it's a different location to your live database.. |
Compress |
Compressing will make the backup file smaller. |
Add Date at end of file name |
This is useful for you to track your latest backups. |
Password |
Add a password for security, if desired. |
Accounts DB only |
Ticking Accounts DB Only includes only the accounting database file, not the document database file (the Document database file stores Jim2 Emails and Documents). The Accounts DB is considerably smaller. |
Scheduled Backup
You can set your preferences here for scheduled backups.
Frequency
You can run daily, daily with hourly incremental log or weekly backups.
Daily
Once selected, Jim2 Server will perform a full daily backup at the time specified.
Daily with Hourly Log
Once selected, Jim2 Server will perform a full daily backup at the time specified, then logged backups will be performed every hour until it is time to perform another full backup.
Weekly Backup
You also have the option of weekly-only scheduled backups.
 |
This option is only recommended for clients performing a reliable alternative daily VSS-aware backup of the Jim2 databases. |
Select the Weekly option with the appropriate time to run
Compress
Compressing will make the backup file smaller.
Add date at end of the file name
This is useful for you to track your latest backups.
Password
Add a password for security, if desired.
Each day a full backup is taken, then smaller hourly incremental backups are taken throughout the day. The process starts again the next day with another full backup, then the hourly incremental set.
The incremental log backup will increase the storage requirements on a daily basis, however they are generally small incremental files.
In the event of major server failure, this gives you a 1 hour recovery point objective, meaning you can restore the databases(s) within 1 hour of when the failure occurred, rather than having to go back to the previous full backup and potentially have to re-key lost data.
The main consideration is the power of the server to do the backups during the day, without Jim2 performance suffering and user experience being affected. The best way to establish this is to turn it on and monitor it. If users complain about Jim2 performance, it is a simple matter of changing to a more suitable form of backup. Likewise if space is an issue.
Restore
Restoring a Backup
|
If you are restoring from an older backup, you will need to run the database update program prior to launching the restored database. This is to ensure the database matches the version of Jim2 you are running. |
▪Ensure Jim2 is closed, and the Jes instance has been stopped.
▪Go to the Restore tab.
▪In the Database field, name your database.
▪In the From field, find the backup you intend to restore.
▪Tick Restore over existing database – this will restore this new database in its place.
▪When ready, click Restore. You will receive a confirmation message for what you are about to do. Ensure everything is correct and click Yes.
▪When the restore is complete, the console will tell you in the lower left-hand corner:
▪You can now exit the Jim2 Server Console.
Restoring From Incremental Backup
The restoring of an incremental backup chain requires all incremental files to be available up until the time of the backup you wish to restore.
The process of restoration is as follows:
1.Restore the full backup with the Log Restore To Follow option ticked.
If you are restoring over an existing database you will also need to tick Restore over existing database, and ensure that the applicable Jes instance has been stopped prior to proceeding. By selecting Log Restore To Follow, a special SQL restore is performed that informs SQL Server that additional incremental log backups are also to be performed. Click Restore and the initial full database restore will be performed.
2.Restoring the incremental log backups will cycle though the process of restoring each of the incremental backups in the order in which they were taken. Should you attempt to restore a log backup in the incorrect order, you will receive an error message and the restore will be aborted.
|
The backup file names will have _logXXXX appended, where XXXX represents the time of the processed hourly backups. |
Continue the process of restoration with the Log Restore to Follow option ticked until you have restored the second last of the incremental chain.
3.Restoring the last of the incremental backups and finalising the restore.
For the final restore, untick Log Restore To Follow, signalling to SQL Server that this is the last one in the incremental chain you wish to restore. Continue with the final restore, and the process is complete.
Upload Azure Option
Adding to the ability to FTP an off-site copy of the database, you can also configure the completed backup to be uploaded to Microsoft Azure blob storage.
Once you have created your Azure account and storage container, enter the details in the location provided and click Apply.
Further information: