Backup · Recovery
Backup / Recovery
What is backup?
- Copy ahead of time (backup), restore after an incident (recovery)
- The last safeguard against data loss
- Regular, separate storage is the key
Once backup and recovery are in place, the question a company asks after an incident changes. It is no longer “The data is gone — what do we do?” but “What point in time do we restore to, and how many hours until the line is running again?” Being able to state your losses in hours is what a backup system really delivers. That is why it is not just an IT task but a business decision that production, sales, and accounting must make together. Unless you first agree on how much the company can afford to lose, buying equipment gives you no standard to measure against.
Practical design starts from two numbers. RPO (recovery point objective) asks, “How many hours of data can we afford to lose?” RTO (recovery time objective) asks, “Within how many hours must operations be back?” Each asset gets its own targets: accounting data during closing might have an RPO of 1 hour and an RTO of 4 hours, while an internal notice board might have an RPO of 24 hours and an RTO of 3 days. Methods fall into full backups, incremental backups that capture only changes, and differential backups that capture everything accumulated since a baseline. Retention is layered too, such as 30 days of daily backups and 12 months of monthly ones. 3-2-1-1-0, which adds “1 copy offline, 0 verification errors” to 3-2-1, is today’s standard, and redundancy (RAID, real-time mirroring) is not a backup: when the original is encrypted, the copy is encrypted at the same moment.
The most common failure in practice is “the backup was running, but recovery doesn’t work.” Failure-alert emails pile up in a spam folder for three months, or the backup storage sits on the same domain and internal network, so ransomware locks the original and the copy in one stroke. These cases keep recurring. The claim that using the cloud or SaaS means it is handled for you is also risky. The provider is responsible only for infrastructure failures, and a file an employee deleted does not come back once the recycle bin retention period passes. Unless you run a real recovery drill at least twice a year, the system is less something you have than something you believe you have, and only by measuring up to the moment operations actually resumed after recovery does your RTO figure become real.
Jaryong KooMarketing PhD and authority in AI, data analytics, and personal branding
John KimAuthor of B2B Marketing Design and CEO of Nanum ConsultingA long-standing IT practice for guarding against data loss. Backup and disaster recovery (DR) systems have become far more sophisticated alongside the cloud and automation.
Consider a hypothetical case. Company A, an auto-parts maker with 320 employees and KRW 78 billion (≈ US$58,357,000) in annual revenue, had its manufacturing execution system (MES) server and every department’s shared folders encrypted by ransomware on a Friday night. Backups ran daily, but the backup storage was attached to the same internal network and was locked along with everything else; the only survivor was a single external disk from three weeks earlier. It took four days to restart the line, and losses totaled about KRW 400 million (≈ US$299,300).
- The Monday after recovery, the CEO asked the IT lead, 'If we get hit again, how many days will it take to get back up?' No answer came, so the CEO called in the production, accounting, and sales leads and had them each set an acceptable downtime for each asset.
- The IT lead tiered the systems: MES and ERP at an RPO of 1 hour and RTO of 4 hours, design drawings and shared folders at an RPO of 24 hours and RTO of 2 days. The policy called for daily incremental and weekly full backups with 30-day retention.
- One set of backups went to the cloud, and another went onto tape every week and was stored in a vault completely isolated from the corporate network. Access was controlled so that media could leave or return only after a General Affairs manager signed the log.
- The team ran a recovery drill every quarter on a Saturday morning. When the first drill took 11 hours to restore the ERP, someone said, 'Isn't that three times the target?' The team caught two permission-setting errors and cut the time to 3 hours 40 minutes by the third drill.
- The following year, when the shared folders were infected again through malware from a partner company, every department was back to work within 6 hours of detection and the production stoppage was limited to half a day, bringing the damage down from the KRW 400 million (≈ US$299,300) range to around KRW 20 million (≈ US$15,000).