If you own or operate a small business, your server backups are your safety net. They’re how you ensure that if something goes wrong, your business can get back on its feet and resume operating as usual. So server backup fails are a pretty big deal.
Here are 6 common server backup fails and what your business can do to avoid them.
Plus, for good measure, we’ve thrown in an analogous internet fail for each. Just to underline how much it’s going to hurt if this happens to you.
6: Destination Fail: Wrong place, wrong time, wrong removable media
If your backup job detects the incorrect destination media attached, the backup job will fail. Server backup software like BackupAssist will label media within a schedule so that it can detect when an incorrect media is plugged in.
For example: if you have a specific USB hard drive that is only backed up to once a month for archival purposes, but you insert it to perform a daily incremental backup. The software will detect the incorrect media and your server backup will fail.
This one is easy to avoid – simply keep an eye on your alerts and backup reports.
Not too painful at all as long as you’re careful – there are worse things that can happen when you connect a device the wrong way…
5. Tape Fail: Your tape drive won’t fire with the safety on
If you’re backing up to tape and finding a job is failing, you might want to check that little switch on the side of the cassette is flicked the right way. This is called a “Write Protect” lock, and most tapes will have them. It stops them from being written over by accident, but unfortunately it can also stop them from being written over intentionally as part of a scheduled backup.
When using BackupAssist, you’ll receive an email report notifying you of the error and alerting you how to resolve it (flick that switch!). Once again, this goes to show the importance of regularly checking your reports and alerts to ensure your backups are behaving as expected.
Being confident you’ve flicked the safety catch is all well and good, but it’s always worth a double check…
4. General Fail: Do you have your permission slip signed?
Both the data you’re backing up and the backup destination will have access permissions that define who exactly can use them. When you set up a server backup job, it will use a backup account that defines permissions that the backup will require.
However, if someone changes these permissions either at the source or destination, the backup job may fail. The simple fix to this server backup fail is to clearly define who has permissions to perform backups of what data, and who is allowed to change those permissions!
Isn’t needing permission fun?
3. Hyper-V Fail: Information overload for VSS
When backing up Hyper-V servers, problems can occur if the VSS times out because the system is too busy. Processing problems on the guest or host, insufficient memory or insufficient processing power can all cause important server backups to fail when using Hyper-V.
This problem can best be avoided by ensuring each guest and host is responsible for just one role or application. Also ensure VMs have adequate resources available. You can find out more about best-practices in this regard by reading our Hyper-V best practices article.
Information overload isn’t just a problem for VMs…
2. Exchange Fail: Your mail server is the touch-feely sort, keep it connected
When conducting an Exchange Server backup, you need to make sure a stable connection to the backup destination is maintained. This holds particularly true when backing up to an iSCSI target or NAS device, because if the connection is lost for even a moment it will cause the backup to fail.
In addition to maintaining a stable connection to avoid mail server backup fails, it’s also a good idea to ensure your backup solution doesn’t rely on a single static backup destination. We cover how best to avoid this in our backup best practices article – definitely worth a read.
Really, we’d always recommend making sure important machines stay properly connected…
1. SQL Fail: Too many logs, not enough storage
With SQL Server backups, transaction logs are used to allow for point in time restores. When these logs are turned on, they add to the amount of data that needs to be backed up. If left unchecked, this will eventually fill up the backup destination and your server backup will fail.
Decent backup software will back up these logs so that they can be used in restores, but truncate them so that they don’t continue to grow in size with each and every backup. BackupAssist does this using the SQL Add-on, which provides point-in-time SQL restores while saving and truncating required logs. This means they won’t cause a server backup fail by filling up and eventually overwhelming the backup destination.
This is the effect watching a backup destination fill up with log files can have on a person…
Know of another common server backup fail?
Tweet us @BackupAssist or post it to our Facebook wall.
Share this article – ’cause knowledge is power!
