Using MSP360 to secure existing database backups in the cloud requires some additional considerations when designing a backup plan. Unlike MSP360 file, image, or SQL Server backups using the MSP360 SQL Server agent, customers need to be careful to design a backup plan that allows for proper database restores based on database retention requirements and backup types performed.
If you're performing database backups (separately from MSP360), then you are leveraging full (the entire database), differential (changes since last full), and transaction log backups (changes since last transaction log backup). The actual terms used by your particular relational database vendor for these types of backups may differ, but the concepts are similar.
Restores of these databases require all the necessary database backups be available at restore time. That means, the full backup, the related differential backup (if you're using them), and the full sequence of transaction log backups are needed to restore the database to desired point-in-time. Because these backups are performed outside of the MSP360 product, MSP360 will not understand the relationships between these files. The onus is on the backup administrator to understand the database backup and retention needs when designing an MSP360 backup plan.
Document the Database
To avoid any issues, it’s important to fully document and be mindful you understand:
- Your established retention needs for the database (e.g. You need to be able to restore as far back as the last 90 days)
- Your database full backup interval (e.g. You perform a full backup once a week)
- Whether database backups always create files with unique names (as opposed to appending new backups into a common backup file)
- Whether these database backups are ever deleted from the default disk backup location before the retention period is met (as you may want to rely on cloud storage for restores)
Once you document these items, you can design a backup plan that ensures the necessary database backups remain in cloud storage according to your retention needs. The last thing a backup administrator wants to tell the DBA team or the business unit that needs a database restored is that the needed backups are no longer available for restore and their request cannot be completed.
Create Two MSP360 Backup Plans
Consider backing up these database backups using a different backup plan from the one that backs up server files (or server images). This ensures that different retention needs for files vs database backups can be adhered to without worry that a change in one affects the other.
In your file backup plan, you can exclude the folders used for the database backups as there's likely little need to back up the same files twice. You should always perform your local database backups to a location used only for that purpose. Avoid mixing the database backups with other files in the same folder as that makes backup plan design and management more difficult.
In your file backup plan, you can simply exclude (uncheck) the folder / folders from the backup or use the Advanced Filter - Skip Folders option to avoid backing up those folders that contain database backups that will be handled by a backup plan designed specifically for them.
MSP360 Retention Settings
When setting up the retention settings for the database backup plan, make sure you set the retention to the number of days plus the full backup interval. As an example, say you are running full backups once a week, running differential backups on the other days, and transaction log backups at some schedule each day. If you need to keep 90 days’ worth of backups, then set the retention to a minimum of 90 + 7, or 97 days. More is fine. Less can get you into trouble. As an example, if you set retention to 90 days, MSP360 will remove the first full backup from cloud storage on day 91, leaving you with differential and transaction log backups that ran the rest of that week orphaned from their needed full backup.
In your database backup file plan, you can use the Retention Policy - Delete Versions Older Than option to prevent backups from being deleted before the required time interval has passed (97 days in this example). Make sure you uncheck the option to Always Keep the Last Version or you'll never truly delete any files with unique names. Also, uncheck Keep Number of Versions for Each File as this option will not be needed with uniquely named database backup files.
If you have a process that deletes the locally created backups before the 97 days (to save local disk space, as an example), then make sure you avoid setting the MSP360 Backup Plan to remove backups for locally deleted files. Uncheck the option Delete Files that have been Deleted Locally.
If your database backups do not create new backup files each time with unique names, then you have to carefully manage the number of versions you tell the MSP360 backup plan to keep. To avoid overcomplicating the backup plan, it’s easiest to prevent issues by unchecking the option Keep Number of Versions for Each File. Let MSP360 keep all versions of all files and remove them according to the retention settings. If you are using the Block-Level Backup option in MSP360, you need to schedule recurring Full backups to ensure MSP360 can properly delete old backup files that had block-level backups performed on them. But for ease of use, it’s best to simply not use Block-Level for these types of backups, as that makes retention settings and full backup scheduling much less complicated.
Wrapping it Up
If you follow these simple guidelines, you'll be able to successfully keep backups of your existing database backup files in cloud storage while adhering to your retention requirements.
Let us know your thoughts in the comments below.
