Backup and immutable storage
Design off-site and on-premise backup around business priorities, useful retention periods, and recovery requirements.
Backup and business continuity
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
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.
Design off-site and on-premise backup around business priorities, useful retention periods, and recovery requirements.
Document recovery procedures, identify dependencies, and conduct periodic testing before a real recovery event.
Watch critical infrastructure and services for availability, unexpected change, and conditions requiring attention.
Strengthen the highest-value controls first and continue improving without overwhelming the organization.
Business continuity
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.

Backup as a service
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.
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.
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.
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 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.
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.
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
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.
Isolate affected machines and accounts, preserve evidence rather than wiping it, and stop the spread before diagnosing the cause.
Establish what was reached, what was taken, and whether personal information is involved, since that determines your legal obligations.
Insurer, legal counsel, and where privacy legislation requires it, affected individuals and regulators. Timelines here are legislated, not optional.
Restore from clean, verified backups in the order the business actually needs services back, rather than the order they happen to restore fastest.
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
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.
Both. CoreData documents recovery procedures and dependencies, then runs periodic recovery exercises so the plan is proven before it's needed for real.
No. Most engagements start proactively, reducing preventable exposure and building tested recovery plans before an incident happens.
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.
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.
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.
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
If nobody knows, a recovery test is the first thing to schedule.