Share this
by Josefine.Fouarge on Jun 25, 2026, 8:00:00 AM
A backup job ran overnight and the report shows green. But is that enough?
A completed backup job and a recoverable backup are two different things. The worst-case scenario is discovering that gap when you actually need to restore something. By then, the configuration can't be fixed any longer.
According to IBM's Cost of a Data Breach Report (2025), 65% of organizations that suffered a breach had not fully recovered from it. That number points less to bad software and more to plans that were never properly set up and tested.
Avoid scrambling when things go wrong by addressing the tough questions that will help you develop a solid, reliable backup plan in advance.
Table of Contents
- How Critical Is Your Data?
- Does the Information Change Regularly?
- How Fast Do You Need to Recover Data?
- When Is the Best Time to Back Up?
- How Long Do You Need to Keep Your Backups?
- What Is Your Plan for Testing Your Backups?
- Build a Backup Plan Worth Having
- FAQ
How Critical Is Your Data?
Data sensitivity determines how much protection a backup plan needs to provide. Not all data carries the same risk if it's lost or exposed. Treating everything the same leads to overprovisioning in the wrong places and blind spots in others.
If your billing system goes down on payroll day, you'll feel it immediately. Databases, billing systems, and ERP platforms are mission-critical and need daily backups at minimum, including longer retention periods and encryption both in transit to the backup storage and at rest. Operational data like emails and shared drives follow a similar schedule. Some business records carry legally mandated retention requirements.
That classification also tells you where additional protection layers belong. Sensitive data should be encrypted and, where possible, stored in an isolated or immutable location that ransomware can't reach even with access to the primary network. And remember, a file share and a medical records database aren't the same conversation.
Does the Information Change Regularly?
Not every dataset needs a nightly job. What drives the cadence is how often the data changes. A database processing daily transactions needs a different setup than an archive folder that hasn't changed in months.
There are different backup types to consider when protecting constantly changing data:
- Incremental backups capture only what changed since the last job, which keeps each backup small and fast to run. The tradeoff shows up during recovery. Restoring from an incremental chain means applying every job since the last full backup in sequence. In practice, the longer that chain, the longer your business stays offline.
- Differential backups capture everything changed since the last full backup. Each one grows larger over time, but restore is faster. You only need two files: the last full and the most recent differential.
- Incremental Forever backups remove the tradeoff entirely. They run a single initial full backup, then capture only changed blocks going forward while maintaining all restore points within your retention window. Storage stays lean and restores from any point in time stay fast. It's the approach that holds up best as your data grows. Here's a full breakdown of how Incremental Forever works.
Never rely on your standard schedule after a major update. If you just migrated servers, updated your core software, or installed a new platform, trigger a manual backup immediately.
How Fast Do You Need to Recover Data?
It's important to know that your recovery speed depends on your architecture, storage, and storage location, as well as the requirements you have to align with, not just based on the backup software.
Think of Recovery Point Objective (RPO) as your data loss threshold. If your RPO is four hours, you're deciding that your business can afford to completely recreate four hours of lost work. Recovery Time Objective (RTO) is your clock to recovery. It's the maximum time your business can survive offline before operations must resume. RPO and RTO are two important KPIs to track, but there's more to measuring backup performance.
As an example, put 2TB of cloud-only backup on a standard 100 Mbps connection. You're looking at 45 to 55 hours of download time before the first file restores (ignoring any potential bandwidth limitations from the cloud storage).
Nearly 1 in 5 SMBs that suffered a cyberattack filed for bankruptcy or closed entirely (Mastercard Small Business Cybersecurity Study, 2025).
Your choice of backup architecture directly dictates your recovery timeline. If speed is the priority, you want a method that avoids rebuilding your data piece by piece during a crisis.
Here's how the three backup types compare:
| Incremental | Differential | Incremental Forever | |
|---|---|---|---|
| Backup speed | Fast | Medium | Fast |
| Restore speed | Slow | Fast | Fast |
| Storage use | Low | High | Least |
In addition to the backup types, for businesses that need a quick recovery, a combination of local and cloud storage offers fast restores from local storage, and offsite protection and long-term retention from cloud storage. The 3-2-1 backup strategy, which involves having three copies of data on two different storage types with one copy stored offsite, remains the baseline standard for achieving this hybrid setup.
When Is the Best Time to Back Up?
Most of your backups can be scheduled during off-peak hours, such as overnight or on weekends. Running a heavy backup job at 2 PM could clog your network bandwidth and slow down user applications.
Set jobs to run automatically so that you don't have to rely on someone remembering to start them every night.
Some workloads may require more than a nightly job. For example, databases with high transaction volumes may require hourly jobs to achieve a meaningful RPO.
Endpoint backups for remote workers follow the same logic. Schedule them during off-hours, when the machine is idle and not competing with active sessions or VPN traffic.
How Long Do You Need to Keep Your Backups?
How long to keep your backups is a compliance decision. But not all data follows the same retention rules.
A practical starting framework by data type:
- Critical data (databases, ERP, billing systems): 90-day minimum, or per applicable compliance requirement
- Operational data (email, shared drives, productivity tools): 30 to 90 days
- Business records (financial documents, contracts, compliance records): 6 to 10 years in most jurisdictions
- Regulated data (HIPAA, GDPR, PCI-DSS, CPRA): per the specific regulation
For businesses in regulated industries or environments, such as healthcare (HIPAA), financial services (PCI-DSS), and any organization handling EU citizen data (GDPR) with active ransomware exposure, add an immutable or air-gapped copy.
For data that doesn't fall under a regulatory requirement, a baseline retention policy still makes sense. One practical example:
- 30 days for keeping data on local storage
- 60 days for keeping data in an offsite location, i.e., cloud storage
What Is Your Plan for Testing Your Backups?
Someone added a new database that wasn't included in the job scope. A file path changed after an application update. The backup kept running and the reports stayed green, but the data being captured was no longer what anyone assumed. To prevent a backup failure like this from occurring during an actual data recovery, you must regularly test a restore under conditions that resemble a real emergency.
Testing should be scheduled. A monthly restore of a representative data set catches most configuration drift. A quarterly full DR drill validates your RTO commitments under realistic conditions. Remember to document every result, as that record is what you would show an auditor who asks for proof. It's also what gives you and your team confidence going into an incident.
Here's a detailed guide on how to build and run a disaster recovery test plan.
Build a Backup Plan Worth Having
On top of everything, don't forget to revisit your backup setup on a regular basis.
- Update the data classification you created during onboarding every time the business changes.
- Look at what your business requires for the RPO and RTO instead of using the software default and adjust it with any changes that might occur.
- If you use retention policy templates, use them as a starting point for your own setup and update them when your data changes.
- Schedule quarterly restore tests and actually run them.
A backup job that just "runs" isn't enough. What matters is whether you can actually restore from it at any given time.
Ready to build a backup plan that holds up when you actually need it? Book a call with a NovaBACKUP backup expert and walk through the right setup for your environment.
Frequently Asked Questions
What is the difference between a backup plan and a disaster recovery plan?
A backup plan defines what data gets protected, how often, and for how long. A disaster recovery plan defines how you get an entire system or business back online after a major incident. It includes roles, communication steps, and recovery targets for critical infrastructure. Your backup plan supplies the raw material a disaster recovery plan depends on, but the two documents solve different problems. Our guide on testing your disaster recovery plan covers how to validate that recovery process specifically.
How often should I review and update my backup plan once it is built?
A backup plan is not a one-time document. Revisit it whenever your infrastructure changes meaningfully, such as adding new servers, software, or storage locations. Beyond triggered updates, a full annual review is a good baseline. Use it to confirm your data classification, RPO and RTO targets, and retention rules still match how the business actually operates.
What does it cost to build out a complete backup plan?
Most of the cost comes from storage and software licensing rather than the planning process itself, which mainly takes staff time. Local storage is typically a one-time hardware cost, while cloud storage is billed monthly based on how much data you retain. Businesses with strict compliance or immutability requirements should expect higher storage costs. Those copies often need to be kept longer and stored separately from primary backups.
Sources
- IBM. Cost of a Data Breach Report 2025. Ponemon Institute / IBM, 2025
- Mastercard. Small Business Cybersecurity Study. Mastercard, 2025
Worth Reading
What to Look for in Cloud Storage for Server Backup | Data Protection Digest | August 2026
What to Look for in Cloud Storage for Server Backup
Share this
