7-Step Method to Back Up Unsupported Datasources in Cove

Cove Data Protection includes several plugins we refer to as data sources (or datasources/sources), for example, Exchange, MsSQL, and MySQL. However, if you are running software we do not have a datasource for, you must ensure the resulting restore will be consistent and error-free.

Backing up an unsupported application with Files and Folders will work without error. However, restoring this data could be inconsistent. During the backup, data within the application could change between Cove backing up one file or another. The restored data will be from a very different point in time. Alternatively, the application could buffer data in memory that has yet to be committed to the disk. For this reason, preparing the data before a Files and Folders backup is essential to avoid a corrupt restore of the application. 

In most cases, the third-party application will have documentation on performing a backup to a local disk. You can use this to write a script to perform that backup before the Cove Data Protection backup runs, then add it as a pre-backup script before your Files and Folders backup.

Setting up Backup Manager for success 

1. Open the Backup Manager directly from the computer. For security reasons, the script tab will only appear from the Backup Manager opened on the local machine.
2. Navigate to Preferences, then Scripts.
   Note: If you have a Profile assigned, you must remove it via the CMC by referring to Section C of the Cove documentation and using No Profile: Profiles. Removing the profile can take 15 minutes to filter through to the device.
3. Add the body of the script. You can enter command line commands into the text box to run the backup commands directly; alternatively, you can write a PowerShell script so it’s easier to handle large code or to secure your database passwords better. For example, adding the following to the script section will run a PowerShell script called backup.ps1: powershell.exe -ExecutionPolicy Bypass -File C:\DBBackup\backup.ps1
   
4. You should set a timeout for the script. This time should be significantly longer than the script’s average run time. It might take some tweaking to get this correct. The script will run by default using the local system account. Still, you can secure the script on your local system by allowing only a specific user to access it and then adding those credentials to the Backup Manager scripts section.
5. Check the « Fail backup on error » option, as you will want to know if the script had issues completing since this should be a critical step in your backup process.
6. Finally, test the script executes as expected with the « Test » button.
7. With the script saved, you can now set that to run as a pre-backup script from the Schedule tab.

Whether you decide to implement this solution or not, if you backup up any data, you should do a test restore to ensure everything works as expected. It is dangerous to test restores on production servers, so it is best to have a test server or hypervisor you can restore to. It is better to perform a test restore before you find yourself in a critical restore situation. Being proactive will save you time, money, and (more?) grey hairs. 

See our documentation here for running scripts via the Backup Manager.

 Other external links for scripting:

• Postgre backup documentation
• MariaDB backup documentation

Ben Fitzpatrick is an Application Engineer at N‑able, working eight years for Cove Data Protection.