Orlando Cloud Backup & Disaster Recovery FAQ

RTO (recovery time objective) is the maximum acceptable duration from the moment of failure to the restoration of normal operations — it constrains the speed of the recovery process. RPO (recovery point objective) is the maximum acceptable data loss expressed as time — it constrains how frequently backups must capture a restorable snapshot. A four-hour RTO means systems must be operational within four hours of a failure event. A one-hour RPO means the backup must have captured a complete snapshot within the hour before the failure. These two parameters drive the architecture: RPO sets the backup frequency and replication schedule; RTO sets the restore mechanism, compute pre-staging requirements, and runbook complexity. Neither has a useful default value — they must be defined per workload class based on business impact analysis. the Dytech cloud and backup services page describes the DRaaS tiers they use to commit to specific RTO/RPO targets for Central Florida clients.

Incremental-forever captures only changed blocks or files since the previous backup job, every run, with no periodic full backup. This minimizes the backup window and storage growth rate compared to traditional full-plus-incremental or full-plus-differential schemes. The tradeoff is restore complexity: recovering to a point in time requires the last full backup plus every incremental in the chain up to the target recovery point. As the chain grows, restore time grows. The standard mitigation is synthetic-full generation: the backup software periodically combines the last full and all intermediary incrementals into a new full image, resetting the chain length without requiring a new full backup job to run against production systems.

Image-level backup captures a block-level snapshot of a volume, producing a restorable image that includes the OS, application state, configuration, and data. It supports bare-metal recovery, P2V/V2V conversion, and granular file restore (most image-backup products expose a file browser against the stored image). It is the appropriate primary method for server workloads where system-state recovery is required. File-level backup operates above the filesystem, backing up files and directories without OS or application state. It is faster to configure for simple file-share backup and sufficient when the recovery target is a pre-existing OS installation needing only data restored — for example, replacing data on a rebuilt NAS. For most SMB server environments, image-level is the correct default; file-level may supplement it for specific NAS or endpoint scenarios.

A synthetic full is a full backup image assembled by the backup software from existing stored data — the last full image plus all subsequent incrementals merged into a new full — without reading any data from the production source. It resets the incremental chain to a known short length, bounding restore time regardless of how many incremental jobs have accumulated since the last real full. For backup programs running incremental-forever, synthetic-full generation is the mechanism that keeps restore performance manageable over time. The scheduling frequency of synthetic fulls is a design parameter: weekly synthetic fulls are common for systems where restore time is a material concern.

Deduplication identifies and stores only unique data blocks, replacing duplicate references with pointers to the single stored copy. For backup workloads, deduplication ratios vary substantially by data type: virtual machine images and file-server backups with large numbers of similar files often achieve 10:1 or higher ratios; databases and already-compressed media files deduplicate poorly. Source-side deduplication processes data before transfer, reducing WAN bandwidth consumption in addition to storage. Target-side deduplication processes at the storage destination. Most enterprise backup platforms support deduplication at one or both tiers. The practical effect on cost depends on the deduplication ratio achievable for the specific workload — which should be estimated before committing to a storage tier size.

Replication seeding is the process of transferring an initial full backup dataset to a remote or cloud target through a high-bandwidth path — typically a physical storage device shipped to a data center or a local-to-cloud accelerated transfer — rather than over the production WAN connection. It is needed when the initial dataset is large enough that WAN transfer would take longer than the operational recovery window allows, or when WAN bandwidth is constrained enough that the transfer would materially impact production traffic. For a 10 TB dataset over a 100 Mbps symmetric connection fully dedicated to backup transfer, the transfer time is roughly 9 days — clearly requiring seeding in most business contexts. After seeding, ongoing incremental replication transmits only changed blocks, which is typically manageable over a production WAN connection with appropriate bandwidth scheduling.

Grandfather-Father-Son (GFS) retention maintains recovery points across three tiers: daily (Son), weekly (Father), and monthly or annual (Grandfather). The retention window at each tier is configured independently. For HIPAA, a common configuration retains daily recovery points for 30 days, weekly for 90 days, and monthly for six years — matching the HIPAA records retention period for medical records in most state contexts. For FTC Safeguards compliance, retention schedules should be defined in the written information security program and match whatever the WISP specifies. GFS configuration is a backup-software setting; the actual retention is enforced either by the backup software's policy engine or by object-lock policies on the underlying cloud storage, depending on whether the retention hold needs to be immutable.

Object-lock (available in S3-compatible cloud storage platforms) applies a retention hold to a stored object at the storage API layer. During the hold period, the object cannot be overwritten or deleted — not by the IAM user that wrote it, not by an account with full admin rights to the bucket, and in governance mode, not without a specific governance-override permission. Compliance mode goes further: even the root account cannot delete the object during the hold period. This enforcement happens at the storage platform level, independent of the backup software, backup service account credentials, or the state of the client network. For backup use cases, it means that a compromise of the backup software service account or the client domain does not give an attacker the ability to delete stored backup data during the hold period. dytech.com/services/cloudcomputing/ outlines how Dytech Group applies immutable storage to backup engagements for Orlando-area businesses. Questions can be directed to (407) 678-8300.

Backup-software checksum verification reads stored backup data and recomputes checksums against the values recorded at write time, confirming that the stored bits match what was written. This catches storage-layer corruption and truncated writes. It does not verify that the backup image is bootable or that applications will function after restore — that requires an actual test restore to a target environment. A comprehensive verification program runs checksum validation automatically on a schedule and performs application-level test restores periodically. The two checks are complementary: checksum validation runs frequently and cheaply; application-level restores run less frequently but provide the only definitive proof that the recovery path works end-to-end. Call (407) 678-8300 to discuss how dytech.com structures verification schedules for managed backup clients.

Microsoft 365's native retention mechanisms — Recoverable Items folder (Exchange), recycle bin (SharePoint), versioning (OneDrive/SharePoint) — are designed for accidental deletion recovery within defined windows, not for arbitrary point-in-time restore across the full data estate. They are also tenant-bound: a ransomware event or account compromise affecting the tenant can reach these mechanisms. A cloud-to-cloud backup solution maintains versioned copies outside the Microsoft tenancy, with configurable retention, granular restore (individual mailbox items, site libraries, or full mailboxes), and storage subject to immutability settings independent of Microsoft's platform. The architectural distinction matters most in scenarios that exhaust the native windows or compromise the tenant itself.