ENTERPRISE BACKUP · RESTORE · BUSINESS RESILIENCE
Novatelia helps define backup copies, retention, recovery priorities and restore validation for selected enterprise systems. Depending on the agreed scope, a design may cover servers, endpoints, Microsoft 365, Google Workspace and cloud workloads, with off-site storage, immutable retention or replication where supported.
Copies and a tested restore. Backup and disaster recovery at Novatelia are defined through a written design for copies and for restoring selected systems. Actual coverage and any recovery commitment depend on that design and the agreement. This page does not describe a universal backup service or a guaranteed recovery time.
Every engagement includes the records named in the approved scope.
Named source, then an approved backup process, then a selected repository, then an optional additional copy, then an authorized restore, then validation. A repository has to be a destination a restore can use. A separate copy may reduce shared failure exposure. Immutability depends on the platform, the configuration, and the lock. A second site is not assumed. Restoration depends on access, dependencies, backup integrity, and the approved procedure.
Conceptual backup architecture — not a live customer system or verified backup configuration.
01
Servers enter the design only when the inventory names them. The backup method has to support the operating system, the hypervisor, and the applications on that server.
02
Endpoints are the devices the inventory authorizes. A general statement that laptops can be backed up does not place every device in scope.
03
Exchange, OneDrive, SharePoint, and Teams-associated data are included only for the tenant in scope, and only for components the selected product supports.
04
Gmail, Drive, and any shared data are included only for the customer account in scope, and only for data types the backup method supports.
05
Workloads are the subscriptions, accounts, regions, and platforms the design names. A cloud account is the live environment. It is not itself a backup copy.
06
The repository is a destination from which a restore can actually be run. A folder, a sync client, or a cloud account without a restore path does not meet that definition.
07
An additional copy can reduce shared failure exposure when it is stored and accessed separately from the primary repository. A second site is included only when the design names it.
08
Immutability is write protection for a defined retention period, where the platform supports a lock and the customer accepts that lock before it is enabled. Encryption, replication, and geographic separation are different controls.
09
A restore needs access, the dependencies the system requires, backup integrity, and an approved procedure. Recovery infrastructure is specified in the recovery plan. It is not created by the backup job.
10
A scheduled restore test records what was recovered and what failed. The result is evidence. A completed backup job is a different fact.
Five source families can appear in a design. Each one is included only when the inventory or the agreement names it. One backup product is not assumed to support every family.
Protection depends on the named applications, operating systems, virtualization platforms, and a backup method those systems support.
Only the managed or authorized endpoints the inventory lists are in scope. A laptop that was never named is outside the design.
Mailbox and file protection depends on the customer’s tenant, the selected platform, the permissions granted, and the coverage the agreement names.
Gmail and Drive protection depends on the customer account, the backup method, and the data types that method supports.
Cloud protection is planned for the subscriptions, accounts, regions, workloads, and platforms the design identifies.
The 3-2-1 idea — three copies, two media types, one off-site — is a planning framework. It is not proof of compliance and it is not a contractual configuration. Offline, air-gapped, or immutable copies are extended options where the platform and the customer accept them. They are not present by default. No vendor product or storage capacity is stated here.
01
The live system, mailbox, or workload people use. It is the source. It is not a recoverable historical copy.
02
A copy written so that a restore of the named data or system can be attempted from a restore point the design keeps.
03
A further copy, included only where the scope names it, with storage and access separated from the first repository as far as the implementation allows.
04
A repository at the customer site or in the same failure domain. It can be fast to restore from and still share power, site, or administrative risk with production.
05
A repository in a cloud service the design names. Placing a copy in a cloud account does not by itself prove geographic isolation or immutability.
06
A location separated from the production site, with its own transfer method, access, and retention. “Off-site” describes placement. It does not automatically mean immutable.
07
Backup administration is limited to the people the design authorizes. The same account that administers production should not be the only account that can delete the copies, where the platform allows a separation.
08
Retention is the period the design and the platform allow. It is not forever. An immutable lock, where used, is accepted before it is turned on because it may not be reversible during the lock.
09
A restore still needs the application, identity, network, and keys the recovered system depends on. The copy does not carry those dependencies by itself.
Immutable retention is write protection for the retention period the platform can enforce. The mechanism, the administrative authority, the storage cost, and the lifecycle are specific to that platform. Recovery of data inside the lock still has to be validated. The design is approved before an irreversible setting is enabled. A customer is not promised the ability to change a retention lock at any time.
A cloud repository is relevant when the design names the service, the access path, the lifecycle, the encryption the platform actually applies, and the restore requirements. A customer’s ordinary cloud account is not assumed to contain a separate backup copy.
An off-site copy needs a separate location, a transfer method, access rules, and a retention period. It can reduce shared site failure. It is still a backup copy, and it is immutable only when that control is configured.
Replication requires an actual secondary environment and defined operational dependencies. Depending on its design, replication can propagate unwanted changes, deletion, or corruption. Replication alone is not a substitute for recoverable historical backups.
Where the tenant is in scope, a design may cover Exchange Online data, OneDrive data, SharePoint data, and Teams-associated data when the selected backup product explicitly supports those components. Microsoft 365 retention, native recovery, and an independent backup are different controls. This page does not promise protection of every chat, channel, metadata field, permission, or historical version.
Microsoft 365 solutionWhere the customer account is in scope, a design may cover Gmail, Drive, and shared data or other workloads only where the method supports them. Live Google Workspace data is not an independent backup. Native retention and a third-party backup are different. The method and the coverage are named, and a restore test checks the data types and permissions the customer actually needs.
Google Workspace solutionA recoverable copy of selected data or systems, kept for the retention the design allows, in a repository a restore can use.
A defined process for restoring required services after a disruptive event. It may require recovery infrastructure, application dependencies, identity services, network access, data restoration, application validation, and an authorized business decision.
Objectives are design inputs. They are assigned to specific systems or services. Different systems may have different priorities. What can actually be achieved depends on the architecture. A target becomes a commitment only when it is explicitly approved in writing. No recovery number is published on this page.
The targeted maximum acceptable data-loss interval, expressed as time.
The targeted maximum acceptable time for restoring a defined service or process following a disruption. It is not the total duration of every business recovery activity.
The sequence below is a conceptual example. The actual order depends on the named systems, the application dependencies, and the approved business priorities. It is not a customer recovery plan and it does not operate a live recovery.
01
Someone with the authority named in the plan decides that recovery starts. This step is a business and operational decision.
02
The recovery environment, power, and platform capacity the plan names have to be available before workloads are restored onto them.
03
Identity, name resolution, and network access are restored where the applications depend on them. The order is the one the design approved.
04
Applications and data return in the approved order. A system that was never in the inventory is not inserted into the example.
05
The recovered service is checked for the behavior and the access the acceptance criteria describe.
06
The owner records what was accepted, what remains open, and who operates the system after the exercise or the incident.
01
The systems, the data, and the success criteria are named before the test. A test of one mailbox does not certify every server.
02
The restore uses a restore point the backup system can present. Selecting it is not the same as proving the data inside it is usable.
03
The restore target is an environment the customer has authorized. A test is not run against production unless that risk was approved.
04
The procedure in the plan is followed. Completion of the restore operation is one fact. Usability is the next one.
05
The recovered mailbox, file set, or system is checked against the criteria. A mounted disk is not yet a business acceptance.
06
What worked, what failed, and what was skipped are written down. This page does not display a sample success log.
07
The recovery owner accepts the result or records the gap. A schedule for the next test exists only when the contract includes it.
The job reported completion. That report does not prove a restore.
A copy is present at a destination. Presence still requires a restore test to show it can be read back.
The product finished a restore into the target. The application may still be unusable.
The application and the data access the test required actually work.
The named owner has accepted the result. Acceptance is a recorded decision, not a product status.
A design records who owns the data, who may administer the backups, who may request a restore, how long copies are kept, whether an immutable lock was approved, and how deletion is authorized. Encryption and key responsibility are recorded where they apply. Regulatory retention and data-residency rules are assessed for the customer and the environment. This page does not state a universal legal retention period.
Relevant controls include administrative privilege, multifactor authentication where the platform supports it, restricted backup-management access, separation of duties, protection of credentials and keys, segmentation, monitoring where a monitor is actually deployed, immutable or offline options where they are supported, and restore validation. This page does not provide an active managed security monitoring service, and it does not state a ransomware-resilience certification.
These records are possible deliverables for the scope that was agreed. Credentials, recovery keys, sensitive topology, and customer system details are not published.
01
The inventory lists the servers, endpoints, Microsoft 365 tenant, Google Workspace account, and cloud workloads that are actually in scope.
02
A backup copy is written to a repository from which a restore can be attempted, on the schedule the design states.
03
An off-site copy, an immutable lock, or both, appear only where the platform supports them and the customer accepts that option.
04
A restore test runs when the engagement schedules it, and the result is recorded. The test is the evidence of recoverability for the scope that was tested.
Enterprise backup is a restorable copy of defined data or systems, written to a destination a restore can use, with retention and access the design names. A configured job is the mechanism. The copy is the result that recovery depends on.
Disaster recovery is a defined process for restoring required services or systems after a disruptive event. It can require recovery infrastructure, application dependencies, identity, network access, data restoration, application validation, and an authorized business decision.
A backup is a recoverable copy of selected data or systems. Disaster recovery is the approved process for returning the services that depend on those copies. Creating backup files does not by itself establish disaster-recovery readiness.
A restore test is a recovery operation that was actually executed against an agreed scope, with the outcome recorded. It is distinct from a backup job that reported completion.
No. Job completion, the existence of backup data, a finished restore operation, a usable system, and business acceptance are separate facts. Only a restore that was run speaks to recoverability for the scope that was tested.
An off-site backup is a copy kept at a location separated from the production site, with its own transfer, access, and retention. Off-site placement is not the same thing as immutability.
Cloud backup is a copy written to a cloud repository the design names, with access, lifecycle, and restore requirements specified. It is not assumed for every cloud account the customer already uses.
No. A live mailbox or a live virtual machine is not a backup. A copy that can be restored is.
Immutable backup storage is a platform-specific write-protection mechanism for a defined retention period. It depends on the product, the configuration, and the lock behavior. It is not encryption, replication, geographic separation, or a physical air gap.
No. Immutability can prevent alteration or deletion of the protected copies during the lock, where the platform enforces that lock. It does not remove every path an attacker can use, and it does not restore a system by itself.
Replication copies data or a system to another environment. Depending on its design, it can also copy deletion or corruption. A backup is a historical restore point. Replication is included only when a second site is part of the design, and it does not replace that historical copy.
The 3-2-1 idea is a planning framework: three copies of the data, on two types of media, with one copy off-site. It is a way to discuss resilience. It is not proof of compliance and it is not a configuration this page applies to every customer.
A physical server can be in scope when the inventory names it and a supported backup method exists for its operating system and applications. The method is confirmed for that server. It is not assumed from the product name alone.
Company endpoints can be in scope when they are the managed or authorized devices the inventory lists. Unnamed devices stay outside the design.
Microsoft 365 mail and files can be protected when that tenant is in scope and the selected product supports the mailboxes, OneDrive, SharePoint, or Teams components the design requires. Native retention is a different control.
No. Microsoft 365 retention and native recovery features keep or recover items inside the service, where those features are entitled. An independent backup is a separate copy with its own restore test.
Gmail and Drive can be protected when the customer account is in scope and the backup method supports those data types. The live Workspace data is not itself an independent backup.
Google Vault is a retention and eDiscovery feature of Google Workspace, available where the edition includes it. An independent backup is a separate copy outside that live service. They answer different questions, and Vault is not described here as a full backup of every Workspace object.
Recovery Point Objective is the targeted maximum acceptable data-loss interval, expressed as time, for a named system or service. It is a design input. A number is published only when a written service defines it.
Recovery Time Objective is the targeted maximum acceptable time for restoring a defined service or process after a disruption. It is assigned to that service. It is not the duration of every business activity that follows an incident, and it is not a measured result unless a commitment defines it.
No. Those figures are not published here. They exist only if a written service defines them.
Priorities are the order in the recovery plan: which systems return first, who owns the decision, and which dependencies those systems need. Different systems can have different objectives. The order is approved with the customer. It is not copied from this page.
A restore test runs on the schedule the engagement names, and the result is recorded. This page does not set a universal interval, and it does not promise testing where the contract does not include it.
No. Retention is the period the design and the platform allow. Immutable lock is optional and only where the product supports it.
No. Replication to a second site is included only when that site is part of the design. A replica can track the source, including unwanted change. An independent recovery copy is a historical backup with its own retention.
A plan names the recovery owner, the order of return, the recovery environment, the dependencies, and the restore procedure for the systems in scope. Infrastructure, identity, network access, data restoration, application validation, and the business decision to start are part of that description when they apply.
Acceptance is the recovery owner’s recorded decision after the restored system has been checked against the agreed criteria. A product status, a job log, or a mounted volume is not that decision.
No. Immutable retention is used only where the chosen platform provides it and the customer accepts the lock. The design is approved before an irreversible setting is enabled.
The related pages are Microsoft 365, Google Workspace, Microsoft Azure, and Cloud and Productivity. Backup coverage for those platforms is still a separate written design.
Open the RFQ draft or contact Novatelia. An RFQ saves a browser draft. It does not publish a price, partner status or quotation reference.
An RFQ saves a browser draft. It does not publish a price, partner status or quotation reference.
The RFQ page keeps a browser draft. It does not submit a quotation or issue a reference.
