How does the number of parallel connections to a storage affect performance?
​What is Backup Retention Policy? How is it implemented?
​How to adjust or control client's CPU usage?
​Network and Anti-Virus configuration for inSync Server

The setting for Max. parallel connections on the storage creation screen defines the upper limit for concurrent backup or restore operations that can be performed on the particular storage.

The number of parallel connections to a storage can affect the data synchronization and storage performance.

If the parallel connections to a storage exceed the set value, then a new connection request from an inSync client will be rejected by the inSync server. It will also log an error message stating that the "Server is Busy, try again later."

The inSync client attempts to synchronize every 10 minutes and it will have to wait to synchronize till a connection becomes available.

Storage throughput is shared by concurrent connections. An excessive number of connections will lead to stress on the storage and impact performance, resulting in slow syncs.

Keeping an optimum value of maximum parallel connection helps client complete syncs faster and permits other clients to sync.

Therefore, it is recommended to keep this value to 10% of the total users assigned to a particular storage.

Go to top

A backup retention policy determines the retention time of data, archival rules, data formats and the permissible means of storage, access and encryption, while weighing legal and privacy concerns against economics and 'need to know' concerns.

An administrator can set a policy on the inSync server to store ‘N’ number of daily, weekly or monthly restore points or snapshots for each user.

inSync uses the GFS (Grandfather–Father–Son) retention method for maintaining hierarchical restore points. The GFS method describes a rotation scheme whereby a daily backup (the son), a weekly backup (the father) and a monthly backup (the grandfather) are created to maintain a hierarchical backup strategy.

Each week, one full daily backup (latest from that week) is promoted from a son to a father and is deemed the weekly backup. Each month, a father (latest from that month) is promoted to a grandfather and is deemed the monthly backup. For the GFS policy to work you will need a successful sync every day.

In order to understand better, consider the following retention policy:

In the above scenario, say a user's device has been backed up successfully for 8 consecutive days. Here the total number of restore points created will be 8. On the 9th day, the restore point created on the first day will get deleted. This is irrespective of whether syncs are completed within the span of those 8 days. This means that even if the user’s device is not synced for a day or two, these days would be taken into consideration when deleting a restore point.

However, the next segments (weeks and months) take care of such ‘Missed Sync’ cases.

Moving to weeks, the last successful sync which took place in a week’s duration (latest restore point of that week) will be made available for restore. For 5 weeks (as defined in the policy above), one restore point per week (latest) will be created (i.e. total of 5 restore points will be available).

The above also holds true for months, where the last successful sync in a month will get stored. Here a total of 2 restore points will be generated (for 2 months).

This kind of restore policy helps in maintaining granular restore points.

Also, for any configuration of the restore points, the last successful restore point is always available and it cannot be deleted. Older restore points will be removed as per retention policy defined; however, for each user the most recent restore point will be retained, and will not be removed no matter what retention policy is set. This will make sure that at least one restore point is available for a user.

All backed up/stored data is encrypted using 256-bit AES encryption and can be accessed only using inSync restore methods (available on server and authenticated clients).

Data cannot be browsed or decrypted using any method other than inSync restore options.

Go to top

An inSync Administrator can set the CPU priority and usage for the backup process on each client. If it is set between 5 to 10, the inSync client backup will be prioritized compared to other active applications. If the CPU priority is set below 5, the inSync backup will be slowed down to reduce CPU consumption.

This setting can be done by navigating to Druva inSync Server Management Console -> Manage Profiles -> Profile Name -> Laptop Backup Schedule Tab -> Laptop Backup Resources -> Edit.

If the Allow users to modify resource settings is checked, the user will be able to adjust the CPU usage from the client side, by clicking to inSync GUI icon from the system tray and then clicking Preferences -->Backup Resources and moving the slider bar as needed. The setting on the client will take precedence over that on the Server.

It is recommended to set priority at least at 4 for incremental backups.

Go to top

The inSync server uses the following 3 ports by default:
​
Synchronization port: 6061

inSync Web Control Panel port: 6065

Web/App restore port: 443

The ports must be opened on the firewall of the server and the network.

The settings in firewall should allow:

It is very important to exclude all the inSync directories from live anti-virus scan/on access scan. Most of the anti-virus software lock the frequently accessed files to scan them, which may cause database corruption.
​
When data is uploaded to data folder, inSync stores references for actual data in the database files. If any anti-virus locks these database files, the inSync server may not be able to update database files and it can lose some of the references. Hence, it is recommended to exclude these directories from an anti-virus scan:

- Storage Data folder
- Storage Database folder
- Storage Database log folder

Go to top