Backup and business continuity

Business continuity in Calgary: backup, disaster recovery, and tested restores.

CoreData designs, monitors, and tests backup and disaster recovery for Calgary businesses, so a ransomware attack, a failed server, or a deleted mailbox does not become a business-ending event.

Layered protection

Security is strongest when protection and recovery are designed together.

CoreData's cybersecurity services reduce preventable exposure. This page covers the other half: making sure important systems and information can be recovered when something still goes wrong.

Backup and immutable storage

Design off-site and on-premise backup around business priorities, useful retention periods, and recovery requirements.

Disaster recovery

Document recovery procedures, identify dependencies, and conduct periodic testing before a real recovery event.

Monitoring and alerting

Watch critical infrastructure and services for availability, unexpected change, and conditions requiring attention.

Practical improvement

Strengthen the highest-value controls first and continue improving without overwhelming the organization.

Business continuity

Recovery has to work under pressure.

A backup is only one part of continuity. CoreData helps identify critical services, recovery order, people, credentials, dependencies, and the decisions that need to be made during an outage.

  • Recovery objectives tied to business operations
  • Documented responsibilities and escalation paths
  • Backup retention matched to actual needs
  • Periodic recovery exercises and lessons learned
External backup drive connected to a laptop

Backup as a service

Managed backup and recovery for Calgary businesses.

Backup as a service means the backup is designed, monitored, and verified by someone whose job it is, instead of being software your team installed once and now assumes is working. The distinction only becomes visible on the day you need a restore.

Designed around recovery, not storage

The starting question is not how much data you have but how long the business can be without each system, and how much recent work it can afford to lose. Those two answers, recovery time and recovery point objectives, drive the design and the cost.

On-site, off-site, and immutable

Local copies for speed, off-site copies for site loss, and an immutable or air-gapped copy so ransomware with administrator access still cannot delete your way back. CoreData works with Datto, Veeam, and AhSay depending on whether the workload is physical, virtual, or cloud.

Monitored every day

Failed and partial backups generate tickets automatically. The most common backup failure we inherit is not a missing product, it is a job that has been quietly erroring for months with nobody watching the report.

Microsoft 365 included

Microsoft protects its infrastructure, not your data from your own users. Deleted mail, purged SharePoint files, and departed-staff mailboxes are your responsibility, and retention defaults are shorter than most businesses assume.

Restores actually tested

A backup job reporting success is not evidence that recovery works. Periodic test restores prove the data is usable and reveal the dependencies that turn a two-hour recovery into a two-day one.

Documented and handed over

What is backed up, how often, where copies live, who can authorize a restore, and how long recovery takes. Written down, so recovery does not depend on one person being reachable.

When something happens

What the first 48 hours look like.

Most organizations discover during an incident that the plan lived in one person's head. The sequence below is what a documented response looks like, and it is written before anything goes wrong, not during.

  1. Contain

    Isolate affected machines and accounts, preserve evidence rather than wiping it, and stop the spread before diagnosing the cause.

  2. Assess

    Establish what was reached, what was taken, and whether personal information is involved, since that determines your legal obligations.

  3. Notify

    Insurer, legal counsel, and where privacy legislation requires it, affected individuals and regulators. Timelines here are legislated, not optional.

  4. Recover

    Restore from clean, verified backups in the order the business actually needs services back, rather than the order they happen to restore fastest.

  5. Learn

    Close the specific gap that was used, and revisit the controls that would have caught it earlier. Every incident should make the next one less likely.

Common questions

What's the difference between backup and business continuity?

A backup protects your data. Business continuity is the full plan around it: recovery objectives, who is responsible, escalation paths, and tested procedures so critical services come back online in the right order during an outage.

Do you test recovery plans, or just document them?

Both. CoreData documents recovery procedures and dependencies, then runs periodic recovery exercises so the plan is proven before it's needed for real.

Is this only for organizations that had an incident?

No. Most engagements start proactively, reducing preventable exposure and building tested recovery plans before an incident happens.

How much do backup and business continuity cost?

Monitored backup is usually part of a managed IT agreement priced per user and device, with storage and retention sized to your recovery objectives. Disaster recovery planning and recovery exercises are quoted as fixed-scope work.

Does Microsoft back up our Microsoft 365 data?

Not in the way most businesses assume. Microsoft protects its infrastructure, not your data from your own users. Deleted mail, purged SharePoint files, and departed-staff mailboxes are your responsibility.

What happens if we are breached right now?

Contain first, then assess scope, then meet notification obligations, then recover from verified clean backups. If you are in an active incident, call (403) 450-3438 rather than reading further.

How often should disaster recovery be tested?

At least annually, and after any material change to systems or staff. A recovery plan that has never been executed is a document, not a plan, and the gap usually shows up in dependencies nobody mapped.

More on backup, recovery, and business continuity is coming soon to the CoreData Blog.

Know where you stand

When did anyone last restore from your backup?

If nobody knows, a recovery test is the first thing to schedule.

Discuss Your Recovery Plan