To keep the data within your SQL server at your fingertips the next time a data catastrophe strikes, follow these best practices.
1. Have an up-to-date offsite backup.
When data loss occurs, it can be caused by disasters within your organization such as flood, fire, or malware. In order for you to maintain the ability to recover the appropriate versions of your data when you need it, you’ll need to have an up-to-date offsite backup to deploy. While having an onsite copy may have its perks (it can be faster to restore), having an offsite copy will ensure that no matter what happens to the equipment and data at your location, you’ll be able to fall back on a backup you know will be there when you need it.
2. Don’t skimp on security.
For many companies, hosting data at an offsite location raises red flags. While this is a fair concern for data when it leaves an organization, it should not be the thing that stops you from maintaining an offsite backup. You can have both the data protection an offsite backup affords on top of maintaining your organization’s strict security standards by storing your backup at a secure data center. The data center you select should have strict access controls (like alarms and armed guards), along with backup power supplies and redundant internet connections so your data stays confidential and is always available when you need it. One rule of thumb to use one selecting a data center: make sure it passes an annual SSAE 16 Type 2 audit for its protocols.
3. Automate your backups.
It’s too easy to forget to schedule or manually run a backup. Technology has made consistency easy, so take advantage of it. By automating your backups, you’re decreasing the chances that an employee will forget to backup a specific folder, file, or forget to run a full backup at all. You can automate your backups by finding a continuous, automatic cloud backup provider with server backup capabilities. The continuous and automatic features will ensure changes made to your data are always recorded so you can find any previous file version you need without ever losing a change.
Shameless plug: the MySQL and MS SQL automatic backup modules are FREE in our Server Pro account.
4. Make sure your settings are correct.
Before you create a backup, make sure the settings in your SQL server are set correctly. Your database Recovery Model should be set to “full” and you should create an account within your SQL server to be used only by your backup provider. Nordic Backup offers a step-by-step tutorial that will walk you through how to get your settings right before you backup your SQL server.
5. Restrict user access.
The fewer people who have access to your backup the better. Once you start providing people with access to your backups, you’re putting them at risk of being accidentally or maliciously tampered with. Limit access to only the few authorized users who need it — these are likely the employees who are responsible for running and restoring your backups.
6. Eliminate the potential for downtime completely.
The speed with which you can recover after a loss and restore your SQL server backup matters. Generally, the longer a restore scenario takes, the more expensive it becomes. This is especially true if the damage done was considerable, as in your entire server goes down. Luckily, you can eliminate the potential for downtime altogether by hosting your server off-site and in the cloud, where it remains preemptively virtualized. With your server virtualized, there’s no wait time between the data loss event and getting back to business.
Create an offsite backup, ensure your data’s security, automate your backups and eliminate downtime.
