Backup & Business Continuity
A business does not back up its systems simply to have another copy of its data. The reason for the backup is what happens when something goes wrong: a file, a server, an application, or cloud information the company depends on is suddenly unavailable.
RPMC helps businesses in Barrie and the surrounding area protect what matters, verify that it can be recovered, and have a realistic path for getting people working again.
The real question
The useful conversation is not about storage capacity or backup software. It is about whether the business can get back what it needs, and whether people can work again.
Only part of the question
By itself, that question only tells you whether another copy exists. It does not tell you whether the copy is the right one, whether it can be restored, or what happens to the business while that work is done.
The one that matters
And can people get back to an acceptable level of work? That is the test. A backup that cannot answer it is not doing its job.
Interruptions come from ordinary technology failures as often as from a security incident.
A file gets deleted
A server fails
Storage becomes corrupted
An application stops working
Hardware has to be replaced
Cloud data needs to be recovered
A security incident damages part of the environment
Start with the business
Not every company needs the same backup or recovery plan. A ten-person company using mostly cloud applications may have very different requirements from a business running physical servers, virtual machines, large file shares, specialized software, or other infrastructure.
Even inside the same company, not every system has equal importance. If one employee loses a file, the recovery need may be straightforward. If the server supporting accounting, production, scheduling, or another critical function goes down, the question becomes larger.
The technology follows from that. The purpose is not to back up everything simply because it can be backed up.
What needs to come back first?
What depends on that system?
How long can the business reasonably operate without it?
Can the existing hardware be repaired, or does it need to be replaced?
Can the system be restored somewhere else?
Does a software vendor need to be involved?
What can employees do while recovery is happening?
How the work holds together
Those four ideas are the spine of a useful backup and continuity design. Storage, software, and destinations are parts of that work, not the point of it.
01
What the business depends on, what interruption it can tolerate, and which systems, files, and cloud information actually need a recovery path.
02
Put recoverable copies in the right places for that environment: the systems that matter, with a local copy and an off-site copy when the situation supports it.
03
Watch the jobs, investigate failures, and test restores in a way that matches what the backup is expected to accomplish when it is really needed.
04
Restore what the business needs, from one file to a larger recovery, and take responsibility for the technical work required to get people working again.
Protect what actually matters
We can protect a wide range of business systems and data, but the right design depends on the environment and what the business needs to recover.
For Managed IT clients, we require server backup where servers are present. If the business uses a file server, its business data is protected as well. From there, protection can expand where it makes sense: individual computers, Microsoft 365 and other supported cloud data, longer retention, different storage destinations, or more extensive recovery capability.
Physical servers, virtual servers, system images, system state, and bare-metal recovery where that is the right design.
Individual computers, folders, and the files people actually work from, when those copies matter to the business.
Microsoft 365 and other supported cloud or business-application information, where the recovery requirement calls for it.
Moving information into Microsoft 365 or another cloud service changes where it lives. It does not automatically mean it is backed up in a way the business can recover from. That decision still has to be deliberate.
Two copies, two jobs
RPMC generally prefers a design with both a local copy and a remote copy when the situation supports it. The specific combination can vary. What matters is choosing the right pair for the business, not forcing every customer into one rigid model.
Local copy
If a large amount of data or a complete system has to be restored, recovering from nearby storage can be considerably more practical than transferring everything back across an Internet connection.
Off-site copy
If the local backup equipment is damaged, lost, inaccessible, or affected by the same problem as the original systems, the business still has another copy stored somewhere else.
One copy helps make recovery practical. The other helps make sure the recovery copy did not disappear with the thing it was protecting.
RPMC’s backup platform can use local storage, removable storage, commercial cloud storage, remote storage, and infrastructure under RPMC’s own control in Canada when a customer’s requirements make that the better approach. Backup information is encrypted at the source.
Local storage
Removable / local backup
Commercial cloud storage
Remote storage
RPMC-controlled infrastructure in Canada
Some organizations have privacy, contractual, institutional, or internal requirements for where backup data lives, who may process it, and who can access the systems containing it. We can design the storage around those requirements, including Canadian data residency and RPMC-controlled infrastructure when appropriate.
A completed job is not the finish line
Seeing that a backup completed successfully is important. It is not the same thing as proving that the business can recover from it.
We centrally monitor the backup environment. Jobs report through the platform, and failures or errors generate alerts for us to investigate.
Restore testing is standard. At minimum, that includes file restore testing, so we are not relying only on a successful-job message to tell us recovery will work.
Test the recovery you actually need
Where the customer's recovery requirements are more demanding, the verification can become more demanding too.
If the job is a file
Standard restore testing checks that a required file or folder can be located, selected, and restored. That is the right test when that is what the backup is for.
If the job is a running system
If an important server needs to be recoverable as a virtual machine when the physical server fails, the procedure can include restoring the image into a virtual environment and verifying that the recovered system starts. That is a deeper test, used where it is part of the agreed recovery procedure.
Recovery can mean very different things
Sometimes recovery means putting one file back. Sometimes the entire server is the problem. We support both, and several points in between. The time required depends on the environment, the amount of data, the infrastructure, the failure, and the recovery design.
One file
Someone deleted something important. The backup is located, the required version is selected, and the file is put back.
Folders and data
Shared information, application data, or a larger set of files the business needs in order to keep working.
Microsoft 365 and cloud
Supported cloud information the business depends on, recovered because that recovery was designed, not assumed.
A workstation
A computer that needs to be restored so a person can return to their work, including system-image recovery where that is the design.
A server
System-state protection, system-image backup, bare-metal recovery, or virtual-machine recovery, depending on the environment.
Another way to get the server running
Where appropriate, a backed-up system can be recovered into a virtual environment. That can matter when the original hardware has failed and the business needs another way to get the server operational.
Related, not identical
Those ideas overlap. Treating them as the same thing can create false confidence. Having a backup does not automatically mean the entire company can resume operations immediately after a major failure.
01
The recoverable copy. The files, systems, and information you would restore from if they were gone or unusable.
02
The technical work and planning required to restore systems, services, and data after a significant failure. Replacement hardware, rebuilt servers, networking, software, and vendors can all be part of that work.
03
How the organization keeps functioning, or returns to an acceptable level of operation, while that recovery is happening. It is the business question, not another name for a backup job.
A serious recovery may also need:
Replacement hardware
Temporary infrastructure
Restored virtual machines
Networking changes
Software reinstallation
Application vendors
Access restored for employees
Decisions about which system gets priority
Clear communication about what people can and cannot use
The right amount of preparation
The right level of continuity planning depends on how much interruption the business can tolerate and what it is prepared to invest in reducing that interruption.
A small business does not automatically need enterprise disaster-recovery infrastructure. It should still know what it would do if the technology it depends on stopped working. A company heavily dependent on a particular server, application, or dataset may need considerably more preparation.
The strongest plan is not automatically the one with the most technology. It is the one that appropriately protects the systems the business depends on and gives the organization a realistic way to recover from the failures it is preparing for.
Designed around the requirement
For some organizations, that is entirely appropriate. The backup exists, it is monitored, and a file can be put back when someone needs it.
Another business may need a complete machine to be restorable, not only selected files, because the server itself is the thing the company cannot work without.
Restoring a large server entirely from the cloud may take too long for that business. A nearby copy changes what is practical.
Another may want regular confirmation that its server image can be restored into a functioning virtual machine, because that is the agreed recovery path.
Some recoveries are not only an IT restore. Line-of-business software and other vendors may need to be part of the procedure.
Our standard retention is about 90 days, but that is not a hard limit. We can extend it where business, contractual, operational, or other requirements call for it. The important question is how far back the business may realistically need to recover.
When it is actually needed
Start with RPMC. We handle the technical work.
We handle both the backup and the restoration work. If replacement hardware is required, we help manage it. If software needs to be installed or configured again, we handle the technical work. If a line-of-business software vendor needs to participate, we work with that vendor.
If a server needs to be restored, virtualized, rebuilt, replaced, or reintroduced into the environment, we manage the technical process based on the recovery plan and the circumstances of the incident. You should not have to diagnose which technology company owns each piece before asking for help.
Backup restoration
Replacement hardware
Server rebuilding and virtualization
Networking and restoring access
Software installation and configuration
Application vendors and cloud systems
Different jobs
Reduces risk, helps detect suspicious activity, contains incidents, and tries to prevent avoidable damage. A security incident can cause a recovery event. So can failed hardware, accidental deletion, corruption, software failure, cloud-data problems, or equipment loss.
Answer a different question: what happens when systems or data are unavailable and the business needs them back? Good security tries to keep an incident small. Good continuity prepares for the possibility that an incident still causes disruption, or that the problem was never a security incident in the first place.
Before something goes wrong
Most businesses hope they never have to use their backup in a serious recovery. That does not make the planning unnecessary. The backup and recovery plan needs to be in place before the failure, and it needs to match what the business is actually depending on.
If important operations depend on servers, applications, data, or cloud information, some form of backup and recovery planning should be part of operating that environment. The sophistication can vary considerably. The need for a recovery path does not.
The right question is not which backup package you want. It is what the business depends on, what happens if you lose it, and how prepared you want to be to recover.
Barrie and Central Ontario
RPMC is based in Barrie and works with businesses across Barrie, Simcoe County, surrounding Central Ontario, Toronto, and the GTA.
A discovery conversation is the place to talk about what is currently protected, how recovery currently works, and whether that design matches the interruption the business can tolerate. You do not need to arrive with backup terminology.