About this interactive
A backup is a point-in-time copy, kept so that systems can be restored when something goes wrong. The worry when you need one is always the same: is it good, and is it the right one? Settling the decisions ahead of time removes most of that.
What to back up depends on whether the data can be recreated. Customer data in a database cannot be reassembled once it is gone; servers in a DevOps shop can be rebuilt from scripts. Criticality, cost, the RPO and RTO, copy times, security and how fast the data changes all decide how often.
Where copies live: onsite copies restore fast, which helps the RTO, but a fire takes them with the originals, so keep an offsite copy too. Encrypt the copies wherever they are kept. Tapes rotate between onsite and offsite sets.
How long: a retention period says how long each backup is kept, and you stick to it. Old data you will probably never use is archived to secure, cheaper storage instead of slowing the live system. When a customer must be erased, the copies in backup and archive have to go too, or the data stays a liability.
Restoring: overwrite the original, restore side by side under a new name, or restore to an alternate path, and tell the user which. Run a media inventory on a tape to see what is on it. A snapshot freezes a file while changes go to a separate delta, which lets a backup copy an open file cleanly; on a virtual machine, a snapshot kept for long slows it down. And test restores, or you find out what is missing when you need it.
About TechKnowSurge
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →