Proudly Canadian 
Backup and Recovery Methodology
A backup has value only when recovery works
Gotekky plans backups as part of an operational recovery process. The method begins with the systems that matter, the data that can be lost, the time available to restore service and the people who must make decisions during an incident.
Start with business impact
Protect the service, not only the files
Recovery planning begins by identifying the workload, its dependencies and the consequence of interruption. A website may rely on a database, object cache, scheduled tasks, DNS, certificates, email delivery, external APIs and provider access. Restoring only one component may not restore the business service.
Gotekky records what must be recovered, the order in which components return, who can authorize a recovery and which third parties may need to participate.
Recovery point objective
The acceptable window of data loss measured in time. A lower RPO generally requires more frequent or continuous data protection.
Recovery time objective
The target time to return a usable service. The target must reflect architecture, data volume, dependencies and validation work.
RPO and RTO are planning objectives, not automatic guarantees. Contractual commitments must be stated in the applicable managed plan or written proposal.
Recovery architecture
Separation reduces the chance that one failure removes every option
The exact design depends on the workload, but the recovery path should not rely entirely on the same server, credentials or failure domain as production.
Applications, databases, configuration and active business data.
Scheduled copies designed for efficient routine restoration.
Off-server or independent storage with controlled access and retention.
Access, dependencies, priorities, validation and return-to-service steps.
Where the technology and risk justify it, the design may include restricted deletion, object locking, offline copies, cross-provider storage or separate administrative credentials. These controls are selected through the service scope rather than promised universally.
Eight-step method
From inventory to an exercised recovery process
Backup software is one component. The method connects technical copies to an operational plan.
Inventory the service
Identify applications, databases, storage, DNS, certificates, scheduled jobs, integrations, access paths and provider dependencies.
Set priorities and objectives
Define restoration order, acceptable data loss, target recovery time and the business decisions required during an outage.
Select consistent backup methods
Choose file, database, image, snapshot or application-aware methods according to how the workload writes and changes data.
Separate copies and access
Reduce dependence on the production system, one provider and one administrative identity. Protect recovery credentials and documentation.
Define retention and lifecycle
Keep enough recovery points to address recent errors, delayed discovery and major changes without retaining data without purpose.
Monitor and verify operations
Review job completion, repository health, available capacity, retention behaviour and failures that require intervention.
Test restoration
Restore representative data or the complete service in an isolated or controlled environment and validate the result.
Exercise and improve the plan
Use recovery exercises and real incidents to update documentation, priorities, access, architecture and future tests.
Protection scope
The recoverable system is usually larger than its data directory
The agreed scope should include everything required to recreate a usable service. The precise components vary by platform and plan.
Application and content
Website files, uploads, application releases, themes, plugins and custom code where included.
Databases and state
Databases, transaction data and application state with a frequency appropriate to the workload.
Configuration
Service configuration, automation, package information and infrastructure definitions needed for reconstruction.
Dependencies
DNS, certificates, email flows, external providers, integrations and the access inventory required for coordination.
Recovery documentation
Priorities, contacts, credentials process, validation checks and the sequence used to return the service.
Security state
When compromise is possible, recovery includes selecting a clean source and preventing restored systems from carrying persistence forward.
Validation levels
Successful jobs and successful recovery are different measurements
Gotekky uses different levels of validation according to the risk and service scope.
Job verification
Confirm that scheduled jobs completed, storage is reachable and failures are reviewed.
Operational signalSample restore
Recover selected files or data to confirm readability, permissions and practical access to the backup.
Data-level proofFull restore test
Rebuild the defined workload in a controlled target and validate application, database and service behaviour.
System-level proofRecovery exercise
Test the technical process together with decisions, dependencies, communications and return-to-service procedures.
Operational readinessIncident execution
Recovery must avoid restoring the original problem
A failed update, hardware loss and security compromise do not use the same recovery path. Gotekky evaluates the incident before choosing a source and destination.
Limit further damage and preserve useful evidence where appropriate.
Identify the affected systems, likely cause and condition of available recovery points.
Choose a recovery source and a clean, supported restoration target.
Recover components in dependency order and control external connectivity.
Test application functions, data, security, DNS, email and integrations before return.
Monitor the restored service, document the outcome and correct the conditions that increased risk.
Operational transparency
What a backup does not guarantee
- A snapshot stored with the same system is not automatically an independent recovery copy.
- Replication can reproduce deletion, corruption or malicious changes when no historical recovery points exist.
- A green backup dashboard does not prove that the application can be restored and used.
- Data without provider access, DNS control, licences or documentation may still leave the service unavailable.
- Restoring a compromised system without validating the source can reintroduce the compromise.
How it connects to Gotekky services
The methodology scales with the importance of the workload
The applicable managed plan or proposal defines the backup frequency, retention, verification, restore testing and recovery responsibilities.
Website and commerce protection
Off-server backups, database protection, plan-specific retention and restore testing for supported WordPress and transaction websites.
View Managed WebsitesServer and platform recovery
Backup oversight, full restore testing, disaster-recovery governance and exercises for supported servers and coordinated environments.
View Managed InfrastructureExisting backup evaluation
Review retention, separation, access, restore procedures and recovery gaps before remediation or a managed-service transition.
View Backup and Continuity AssessmentRecovery in practice
Restoration is only one phase of a safe recovery.
See how Gotekky separated containment, recovery-source evaluation, restoration, persistence review and stabilization after a production environment was compromised.
Questions
Backup and recovery methodology FAQ
Is a server snapshot a complete backup?
Not automatically. A snapshot can provide a useful rollback point, but recovery also depends on separation, retention, access, consistency and the ability to rebuild the complete service safely.
What are RPO and RTO?
RPO describes the acceptable amount of data loss measured in time. RTO describes the target time to return a usable service. Both are selected according to business impact and technical reality.
How often should recovery be tested?
The frequency depends on criticality, complexity and rate of change. Gotekky separates routine job verification, sample restores, full restore tests and broader recovery exercises, then defines the cadence in the managed plan or proposal.
Can Gotekky manage backups for infrastructure hosted elsewhere?
Yes, when the platform, access model and backup technology are supported. The architecture may use Gotekky infrastructure, an approved external provider or a coordinated combination.
Prepare before the incident
Know what can be recovered before you need it
Start with a free conversation about the workload, current backups, providers, business impact and recovery expectations. If the environment requires hands-on investigation, Gotekky can scope a backup and continuity assessment.