Honestly, it might not really be worth it to get a course on backups because there's no industry standard from which to teach. Every vendor has something that makes them different. Your best bet is to talk to a VAR about what you want to do, and take their recommendation as a starting point and research them on google. There are of course key concepts and terms you will want to learn, but it's a fairly short list to research and you will have enough information to make a plan. Here's a list to get you started: <b>RTO: recovery time objective</b> the amount of time you can afford to be without a system while you recover from a loss. <b>RPO: recovery point objective</b> the amount of data you can afford to lose if you have to recover a system <b>archive depth</b> how far back into the past you want to keep data <b>tape library/autoloader</b> a device that has tape drives and a way to store, load, and unload tape media <b>backup media server</b> a server that runs your backup software which runs your backup media <b>backup agent</b> software you run on a production server that needs to be backed up <b>hot backup (for databases and open files)</b> a special type of backup agent that will ensure your copy of a file system with open files or a database is bootable (consistent) before performing the backup <b>consistency point</b> a point where all outstanding writes have been committed to disk, ensuring that a server can boot from the data <b>full backup</b> a complete copy of an entire server's data <b>incremental backup</b> a copy of the changes that have happened since the last full or incremental backup <b>VTL: virtual tape library</b> a disk system that pretends to be a tape device for faster backups and restores <b>disk to disk to tape (D2D2T)</b> a multi-phase strategy where you send all backups to disk for a while before committing them to tape <b>backup encryption</b> encrypting your backups so when (not if) you lose a tape (or whatever), it can't be trivially read <b>backup deduplication</b> if you use a disk device as a stage in your backup, you can use a deduplication algorithm to ensure you only backup any given chunk of data once <b>disaster recovery site</b> a physically discreet site where copies of your data can be kept in case of emergency My last piece of advice: all hardware eventually breaks, and all software eventually works. Your most frequent restores are going to be trivial from human error, and your most catastrophic and infrequent restores will be from site or hardware failure, and somewhere in the middle lies firmware patch issues that can take down your entire system.

Honestly, it might not really be worth it to get a course on backups because there's no industry standard from which to teach. Every vendor has something that makes them different. Your best bet is to talk to a VAR about what you want to do, and take their recommendation as a starting point and research them on google. There are of course key concepts and terms you will want to learn, but it's a fairly short list to research and you will have enough information to make a plan. Here's a list to get you started: <b>RTO: recovery time objective</b> the amount of time you can afford to be without a system while you recover from a loss. <b>RPO: recovery point objective</b> the amount of data you can afford to lose if you have to recover a system <b>archive depth</b> how far back into the past you want to keep data <b>tape library/autoloader</b> a device that has tape drives and a way to store, load, and unload tape media <b>backup media server</b> a server that runs your backup software which runs your backup media <b>backup agent</b> software you run on a production server that needs to be backed up <b>hot backup (for databases and open files)</b> a special type of backup agent that will ensure your copy of a file system with open files or a database is bootable (consistent) before performing the backup <b>consistency point</b> a point where all outstanding writes have been committed to disk, ensuring that a server can boot from the data <b>full backup</b> a complete copy of an entire server's data <b>incremental backup</b> a copy of the changes that have happened since the last full or incremental backup <b>VTL: virtual tape library</b> a disk system that pretends to be a tape device for faster backups and restores <b>disk to disk to tape (D2D2T)</b> a multi-phase strategy where you send all backups to disk for a while before committing them to tape <b>backup encryption</b> encrypting your backups so when (not if) you lose a tape (or whatever), it can't be trivially read <b>backup deduplication</b> if you use a disk device as a stage in your backup, you can use a deduplication algorithm to ensure you only backup any given chunk of data once <b>disaster recovery site</b> a physically discreet site where copies of your data can be kept in case of emergency My last piece of advice: all hardware eventually breaks, and all software eventually works. Your most frequent restores are going to be trivial from human error, and your most catastrophic and infrequent restores will be from site or hardware failure, and somewhere in the middle lies firmware patch issues that can take down your entire system.