Architecture and operating model
A backup MX appliance and a cloud Backup MX service address continuity through different operating models. Compare independent failure domains, maintenance ownership, capacity and recovery evidence alongside acquisition cost.
With physical or virtual appliances, the organization or its service partner owns operating system maintenance, storage, patching, certificates, monitoring and resilience. A second device sharing power, connectivity and administrator accounts with the primary may fail during the same incident. Separate location and management boundaries belong in the design.
A cloud service can reduce local hardware acquisition and some maintenance work, but provider outage behavior, data processing terms, administrative access and capacity limits still require review. Subscription does not remove every customer responsibility: DNS, destination acceptance, recipient information and incident follow-up remain important.
Doz Teknoloji compares both models against existing staff and infrastructure. Independent-site appliances may suit strong local-control requirements, while managed cloud service may reduce maintenance for a small team. SecuraWall is a cloud service example here. If content filtering is required, assess the security gateway scope separately from standalone Backup MX.
- 1Business and data requirements
- 2Failure domains and ownership
- 3Cost at equivalent scope
- 4Pilot and recovery exercise
Design parameters
- Independence
- Assess power, connectivity, location, DNS and administrator identity separately; device count alone is not evidence of resilience.
- Operational ownership
- Assign patching, certificate renewal, disk capacity, alerting and out-of-hours response.
- Cost boundaries
- Include hardware, licensing, second site, connectivity, staff time, renewal and exit over the same period.
- Data and exit
- Ask about temporary message location, record access, deletion behavior and queued messages when the subscription ends.
Compare operational responsibilities
These are general design criteria. The selected appliance, contract and deployment model can change the result.
| Criterion | Organization-operated appliance | Managed cloud service |
|---|---|---|
| Infrastructure maintenance | Planned by the organization or service partner | Shared according to provider scope |
| Outage independence | Separate power, connectivity and location must be designed | Provider failure domains must be assessed |
| Capacity growth | Requires storage, compute and licensing planning | Requires review of package limits and growth terms |
| Cost | Investment and continuing operations | Subscription and additional operating costs |
| Delivery accountability | Monitor queue and destination acceptance | Correlate service records with destination acceptance |
Worked example
In a completely illustrative three-year calculation, assume a 2,400 USD appliance, 80 USD monthly for a second site and connectivity, and 50 USD monthly maintenance labor. Total cost is 2,400 + 36 × (80 + 50) = 7,080 USD. A cloud option at 40 USD monthly plus 15 USD internal operating effort totals 1,980 USD. These are calculation inputs, not market prices or a SecuraWall quotation.
Check equivalent scope before interpreting the difference: how many domains, what queue capacity, which support hours and which independent failure domains are included? A cheaper option that cannot meet required data location is not justified by cost alone. Run the same outage and recovery exercise for both options and compare more than purchase price.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Both devices fail together | Shared power, connectivity or management may be responsible. | Map all components affected by a single incident. |
| Low subscription but unexpectedly high total cost | Support, additional scope or internal effort may be omitted. | Recalculate total cost for equivalent periods and service boundaries. |
| Pending mail is unclear during migration | Queue ownership at exit may not have been planned. | Reconcile accepted messages and the closure schedule in writing. |
Acceptance checks
- Use the same requirements for appliance and cloud options.
- Verify shared failure domains and independent administrative access.
- Assign owners to all maintenance tasks.
- Calculate total cost over equivalent periods and scope.
- Review data handling, capacity and exit conditions.
- Compare options using the same outage and delivery exercise.
Related concepts
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Capacity and usable headroom
Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Primary documentation
Explore cloud email security and continuity
Review cloud email security and Backup MX options with SecuraWall MailFlow, operated by Doz Teknoloji. Assess setup requirements against your existing mail infrastructure.
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.