Have you used differential backups without completely protecting the full backup?

If so, you’re not alone. According to a recent TechValidate™ study, today’s DBAs rely heavily on SQL Server and yet many are so frustrated by long backup times that they have compromised the integrity of their data in order to speed up protection efforts. Recent research by TechValidate revealed that 74 percent of  database administrators (DBAs) believe SQL Server® backups take too long, and that 55 percent believe backup storage costs are excessive. These are significant concerns given that over half of the respondents (59 percent) operate at least 10 mission-critical SQL Server applications, and about one-fourth (27 percent) operate more than 50 mission-critical SQL Server applications.

In order to address these concerns, some DBAs take actions that — despite their good intentions — end up compromising the integrity of backup and recovery efforts. These include waiting longer between backups, using differential backups without always completely protecting the full backup and shortening retention periods by intentionally or inadvertently deleting critical backups too soon. Most DBAs struggle constantly to achieve the optimal tradeoff between backup speed and the storage space savings that result from deduplication and compression. Unfortunately, in performing many of these tasks, and despite best efforts, mistakes can happen.
Ensuring an efficient and reliable restore process is only one-half of the recovery story. The other half is protection against SQL mistakes to the underlying data. An incorrect SQL statement (one run accidentally in production instead of development) or malicious code designed to change or delete data can easily take production applications offline.

So how can DBAs protect themselves from these types of mistakes?  

For more information: https://software.dell.com/whitepaper/avoiding-5-painful-backup-recovery-mistakes825522