How often should our backups run?

It depends on how much work you can afford to lose. Systems handling continuous transactions often warrant hourly or more frequent protection; document environments are commonly protected several times a day; archives can be less frequent. We set frequency from the recovery point objective you agree to per system rather than applying one schedule to everything.

Is a copy on an external drive or NAS enough?

It is a start, but not sufficient on its own. Local-only copies are lost to fire, flood, theft and site damage, and are usually reachable by the same credentials an attacker would compromise. A defensible arrangement includes an offsite copy and immutable retention that cannot be deleted during its lock period.

Does Microsoft 365 back itself up?

Not in the way most people assume. Microsoft protects platform availability and provides limited retention and recycle-bin windows, but it does not guarantee recovery of content deleted or altered months earlier. Independent backup of Exchange Online, SharePoint, OneDrive and Teams closes that gap.

How long would recovery actually take after a ransomware attack?

Realistically longer than restoring data, because containment, investigation, clean rebuilding and credential resets all come first. That is why we measure restore times during testing and document a recovery order. Organizations with immutable offsite backups and a written runbook recover in a fraction of the time of those improvising.

Do you back up laptops as well as servers?

Yes, and it matters more than it used to. Staff working from home or client sites keep meaningful work locally even when policy says otherwise. Endpoint backup, combined with OneDrive or SharePoint sync for working documents, covers the realistic scenarios of theft, damage and loss.

Can you take over backups that another provider set up?

Yes, and the first thing we do is verify them: what is actually included, whether retention matches expectations, whether the copies are immutable and offsite, and whether a restore genuinely works. Inherited backup configurations are one of the most common places we find serious gaps.

Backup & Disaster Recovery · St. Catharines

Backup and Disaster Recovery in St. Catharines

Backup is the control every organization believes it has and comparatively few have verified. The uncomfortable questions are simple: when was a restore last tested, how much work would be lost, how long would recovery take, and could an attacker who holds your administrator credentials also delete the backups?

Griffin IT Group designs and operates backup, disaster recovery and continuity arrangements for St. Catharines organizations — with recovery objectives written down and restores proven rather than assumed.

Request an IT Assessment Call (289) 667-4000

Definitions that matter

Backup, disaster recovery and business continuity are three different things

These terms get used interchangeably in sales conversations, which is how organizations end up with one and assume they have all three.

01
Backup
Copies of data retained so that individual files, mailboxes, databases or whole systems can be restored to an earlier point in time. Backup answers: can we get the data back?
02
Disaster recovery
The plan and capability to bring systems back into service after a significant failure — a failed server, a flooded comms room, a ransomware event. Disaster recovery answers: how fast can we operate again, and in what order?
03
Business continuity
How the organization keeps functioning while recovery happens: which processes continue manually, how staff are informed, how clients are communicated with, who makes decisions. Continuity answers: what do people actually do that morning?
04
Why the distinction is expensive to ignore
An organization with good backups and no recovery plan still loses days deciding what to restore first, locating licence keys and rebuilding configuration nobody documented. The data survived; the operation did not.

Design

Designing protection around recovery objectives

Good backup design starts from two numbers, agreed with you rather than assumed by us. Recovery point objective is how much work you can afford to lose, expressed in time — an hour of order entry, a day of document editing. Recovery time objective is how long a system can be unavailable before the impact becomes serious.

Those numbers vary by system, which is the point. A patient scheduling platform or a production system may need a very short RPO and RTO. An archive share can tolerate far more. Applying one aggressive standard to everything is expensive; applying one relaxed standard to everything is negligent.

From the objectives we design frequency, retention, storage location and recovery method: local copies for fast restores, offsite copies for site loss, immutable retention so nothing can be altered during its lock period, and image-level protection where a whole server needs to come back rather than individual files.

We also define what is explicitly out of scope. Knowing that a particular vendor-hosted platform is protected by the vendor — and confirming what that protection actually covers — is part of the design, not an omission to discover later.

Ransomware

Backups are the primary target, so they are protected accordingly

Modern ransomware operators look for backups before they encrypt anything. If the backup server is joined to the same domain, reachable with the same administrative credentials and holding the only copy, then compromising one account removes both your production data and your recovery option simultaneously.

We design against that specifically: immutable storage that cannot be modified or deleted within the retention window, credentials separated from production identity, multi-factor protection on backup consoles, offsite copies outside the reach of a domain compromise, and alerting on backup configuration changes or deletion attempts.

Recovery from an incident also needs sequencing. Restoring infected systems into a network that has not been cleaned reinfects them. The runbook covers containment, forensic preservation, clean rebuild order, credential resets and validation before systems return to service.

Immutable retention locks
Credentials separated from production
MFA on backup administration
Offsite and isolated copies
Alerting on deletion attempts
Air-gapped or object-locked storage
Clean-room recovery approach
Documented restore order
Credential reset procedures
Post-recovery validation checks

Coverage

What we protect

Protection has to cover the whole environment, not just the file server. Data now lives in a lot of places, and each has its own recovery characteristics.

Physical and virtual servers
Hyper-V and VMware environments
Databases and application data
File shares and NAS storage
Windows and macOS workstations
Laptops used outside the office
Exchange Online mailboxes
SharePoint and OneDrive content
Microsoft Teams data
Entra ID configuration
Azure and AWS workloads
SaaS platform exports where supported
Network device configurations
Firewall and system documentation
Encryption keys and recovery credentials
Licence and vendor records

Verification

A backup nobody has restored is a hypothesis

Backup software reports success far more often than it delivers recovery. Jobs succeed while excluding a newly added volume. A database is backed up in a state it cannot be restored from. Retention expires earlier than anyone intended. An agent silently stops reporting on the one server that matters most.

We monitor jobs daily, investigate failures rather than acknowledging them, and perform restore testing on a defined schedule — individual files, mailbox items, database recovery and full system restores depending on the environment. Test results are recorded, including how long the restore took, which is the only honest way to know your real RTO.

That evidence is increasingly requested externally. Insurers ask whether backups are immutable and tested; enterprise clients ask about recovery capability in vendor reviews. Being able to produce dated test records changes those conversations completely.

Daily job monitoring
Failure investigation, not acknowledgement
Scheduled file-level restore tests
Mailbox and document recovery tests
Full system restore validation
Measured recovery times
Coverage audits after infrastructure changes
Retention verification
Documented test evidence
Reporting for insurers and clients

Continuity

Planning for the morning something is actually down

A disaster recovery plan is only useful if it can be followed under stress by whoever is available. Ours are written as runbooks: what to check first, who declares an incident, who to contact at each vendor, which systems come back in what order, where credentials and licence information are stored, and how progress is communicated.

Continuity planning covers the human side. Which processes can operate on paper for a day. How staff are notified when email is unavailable. What clients are told and by whom. Which single deliverable or deadline absolutely cannot slip and therefore dictates recovery priority.

Plans need reviewing, because environments change faster than documents. We revisit recovery objectives, contact lists, system inventories and dependency assumptions at least annually and after any significant change.

For organizations with genuinely low tolerance for downtime, we design warm standby capability — replicated virtual machines or cloud failover targets that can be brought up in a fraction of the time a rebuild would take. That costs more, which is exactly why the decision belongs with you, made against a clear picture of what a day of downtime is worth.

Questions

Frequently asked questions

How often should our backups run?: It depends on how much work you can afford to lose. Systems handling continuous transactions often warrant hourly or more frequent protection; document environments are commonly protected several times a day; archives can be less frequent. We set frequency from the recovery point objective you agree to per system rather than applying one schedule to everything.
Is a copy on an external drive or NAS enough?: It is a start, but not sufficient on its own. Local-only copies are lost to fire, flood, theft and site damage, and are usually reachable by the same credentials an attacker would compromise. A defensible arrangement includes an offsite copy and immutable retention that cannot be deleted during its lock period.
Does Microsoft 365 back itself up?: Not in the way most people assume. Microsoft protects platform availability and provides limited retention and recycle-bin windows, but it does not guarantee recovery of content deleted or altered months earlier. Independent backup of Exchange Online, SharePoint, OneDrive and Teams closes that gap.
How long would recovery actually take after a ransomware attack?: Realistically longer than restoring data, because containment, investigation, clean rebuilding and credential resets all come first. That is why we measure restore times during testing and document a recovery order. Organizations with immutable offsite backups and a written runbook recover in a fraction of the time of those improvising.
Do you back up laptops as well as servers?: Yes, and it matters more than it used to. Staff working from home or client sites keep meaningful work locally even when policy says otherwise. Endpoint backup, combined with OneDrive or SharePoint sync for working documents, covers the realistic scenarios of theft, damage and loss.
Can you take over backups that another provider set up?: Yes, and the first thing we do is verify them: what is actually included, whether retention matches expectations, whether the copies are immutable and offsite, and whether a restore genuinely works. Inherited backup configurations are one of the most common places we find serious gaps.

Keep reading

Related St. Catharines services

Next step

Verify your backup and recovery position

We will review what is protected, what is missing, how long recovery would really take and whether your backups could survive a credential compromise — then put the findings in writing.