Today hasn’t been one of your best
at the office…your SQL data is corrupt and you have to restore from a tape
backup. As if things weren’t bad enough, tape backups can take many hours
- if not days to HOPEFULLY recover your data! Let’s say that your SQL
restored, but it’s the version of the last tape backup! Now your organization
has to recreate the lost data that was not covered from the last full
backup. The ripple effects can impact the entire organization. To
add insult to injury, the data loss could result in compliance violations and
heavy fines. Now you are trying to figure out how to break this to your
manager who needs critical information housed on the server prior to a client
meeting in an hour!
With this scenario, it would be safe
to say tape-based solutions are not your safest method of preventing costly SQL
data loss and application downtime. The most reliable solution would be
one that provides offsite disaster recovery while enabling continuous,
on-demand access the moment a disaster happens – with minimal loss of data or
productivity.
When the SQL Server goes down,
profits follow. Ensure business continuity and rapid disaster recovery by
avoiding these common SQL Server backup and recovery mistakes:
Mistake: Writing
backups directly to tape.
Solution: Use
an offsite backup service provider to enable you to immediately identify where
to find the file when you need it. Doing so will make the recovery
process faster and more reliable. The virtualized infrastructure of an
offsite solution has the capacity to identify the exact point the restoration
needs to take place.
Mistake: Failing
to test backups.
Solution: It’s
important to test your full, differential and transactional log backups on a
standby or developmental server at least once a month. Although it’s not
necessary to test all backups that you create, you should at least go through
the testing cycle for a full recovery just to become familiar with the
process.
Mistake:
Failing to check success of backups.
Solution:
Check your scheduled jobs every day to ensure they are successfully
completed. In the midst of doing so, observe the length of time the job
took to finish and make sure everything is running according to baseline, and
completed within the backup window.
Mistake: Writing
backups to the same disks as data files.
Solution:
Create your backup files on a separate disk to avoid the chance of losing both
your data and backup files. The best option would be to hire an offsite
backup service and disaster recovery company to backup your files on a
virtualized server in the event of a complete server failure within your
organization.
Share some of your stories and
lessons learned on backing up your data in the comments section below.
Also, be sure to download RenovoData’s SQL whitepaper.
Fact: According to the National
Computer Security Association, without adequate backup it takes:
- 19
days and $17,000 to recreate just 20 MB of lost
sales/marketing data
- 21
days and $19,000 to recreate just 20 MB of lost
accounting data;
- 42
days and $98,000 to recreate just 20 MB of lost
engineering data.