The CodeTwo Backup architecture resembles a client-server model. There are two main components of this software: Backup Service and Administration Panel. Both have to be installed together but serve different purpose and run independently from each other.
|Fig. 1. CodeTwo Backup architecture.|
CodeTwo Backup Service is the core component of the software. It is responsible for handling the Backup and Restore Jobs, it saves and accesses the data in the Storages, runs Retention Policy processes and Archive, PST Archive and Import Jobs. Backup Service runs seamlessly in the background as a Windows service and features a built-in scheduler which keeps tabs on the schedule for the user, as the name suggests. That means the Backup Service will automatically execute any jobs predefined by the user without him or her having to remember about the job or to manually confirm them when the time comes. As the service runs under the Local System account, the admin does not even have to be logged on to the machine. It is enough to just keep the machine running and the Backup Service will do the rest.
The Administration Panel serves the purpose of configuring the Backup Service by the end user - no surprise here. However, aside from creating jobs, configuring scheduler, setting up servers connections or starting one-time jobs, the Administration Panel allows a little bit more. From within the Panel, an admin can check the Backup Service status. If any issues arise, the Dashboard of the Administration Panel will present alerts. A user can review them and access the software log files for further investigation. Moreover, the Storages can be created, mounted/unmounted, archived or imported, as well as the backed up data can be previewed with the Backup Viewer. The Administration Panel can be ran by anyone who has access to the server but there are built-in security options available for ensuring the process and data safety.
There is also an additional component of the software - the Indexer. This service runs quietly in the background indexing keywords of the backed up data to a separate index database in each Storage. The purpose of this process is to catalog all items contents. This is required for the search feature to work. The Indexer starts to work when the Backup process is finished. Therefore, you might notice that even though Jobs are not running anymore, the software still takes some resources - this would be the Indexer working on the recently backed up data. Please note that a separate instance of Indexer is started per each Storage. That means, if you start multiple Backup Jobs, each configured to back your data up to a separate Storage, this may take considerable amount of resources (mostly hard drive usage). Be aware, that the Indexer runs completely independently and it is governed on its own. A user is not able to interfere with the Indexing service work, customize it, disable it, etc. So if you know beforehand that you will be configuring lots of jobs saving data to many storages, it might be wise to install the software and keep storages on a dedicated machine with fast drives. You may also try to optimize drive workload by using less number of storages.