← Insights·Infrastructure Security

Backup Policy: Local, Cloud, and the 3-2-1 Rule

May 31, 2026·2 min read

Diagram of the 3-2-1 backup rule showing production data on the left with three flow lines fanning out to three destination boxes: a local disk array for fast restore, a local NAS or object store on different media, and an offsite immutable cloud copy below an offsite boundary line. A bottom strip lists five equally weighted policy controls: retention, encryption, access control, monitoring, and restore test.

Owning a backup tool is not the same as having a backup policy. A policy says what is protected, how often, where copies live, who is responsible, and how restore is tested. The 3-2-1 rule, combined with local and cloud copies, is still the simplest way to make sure one failure does not take the business down.

Every company needs backups, but having a backup tool is not the same as having a backup policy.

A good backup policy defines what needs to be backed up, how often, where the backups are stored, who is responsible, and how recovery is tested.

The best approach is usually a combination of local and cloud backups.

Local backups are useful because they are fast. They help restore files, servers, and systems quickly when something breaks, gets deleted, or needs to be rolled back.

Cloud backups are important because they protect the company when the local environment is damaged, encrypted by ransomware, lost, or unavailable.

This is where the 3-2-1 backup rule earns its place.

3 copies of the data.
2 different types of storage.
1 copy offsite or in the cloud.

This simple rule reduces the risk of losing everything to one failure, one mistake, or one attack.

A strong backup policy should also include retention, encryption, access control, monitoring, and restore testing.

Snapshots can help, but they are not a full backup strategy. They are useful for quick recovery, but they should not be the only protection.

The goal is simple.

When something goes wrong, the company should know exactly what can be restored, how long it will take, and who is responsible for the recovery.

Backup is not only about saving data.

It is about making sure the business can keep working.

// related reading

API security with backend validation diagram. On the left, an untrusted client panel showing a browser UI with a hidden DELETE button, a disabled ROLE field, and the URL /api/tickets/42 with the 42 underlined as 'attacker changes this', plus four amber pills indicating client-side manipulation: changed ID, modified payload, direct API call, bypassed UI. Amber arrows representing manipulated requests flow into the right panel, a backend pipeline labeled THE REAL ENFORCER. The pipeline runs each request through six teal gates top to bottom: AUTH (is the user logged in?), AUTHORIZATION (can this user do this action?), OBJECT-LEVEL AUTHZ (can this user access this record?), INPUT VALIDATION (does this payload make sense?), RATE LIMIT (is this request too frequent?), LOG + MONITOR (should this be recorded?), exiting into an APPROVED REQUEST arrow, with a side branch from OBJECT-LEVEL AUTHZ to an amber 403 · DENIED pill, and a callout noting every request is treated as possibly manipulated. Below, a strip of seven equally weighted controls: backend-side validation, object-level authorization, input sanitization, rate limiting, clear error handling, logging plus monitoring, and abuse protection, with a small tag reading 'frontend helps · backend enforces'.

Infrastructure Security

API Security: Do Not Trust the Client

The frontend can hide buttons, disable fields, and guide the user through the right flow, but anything that comes from the client can be changed. Attackers swap IDs in URLs, edit payloads, call the API directly, and bypass the UI completely. Real security lives in the backend: authentication, authorization, object-level access checks, input validation, rate limits, and logging on every request, because every request is treated as possibly manipulated.

Read article

Certificate expiration risk diagram. On the left, a CERTIFICATES EVERYWHERE panel showing ten services that quietly depend on a valid certificate, website, API, VPN, load balancer, mail, internal services, Kubernetes ingress, monitoring, identity, and integrations, with two services (WEBSITE and IDENTITY) flagged in amber as EXPIRES SOON, and a footer pill reading 'all depend on a valid cert'. On the right, an amber-bordered WHEN A CERT EXPIRES panel listing the immediate impact: users cannot log in, APIs fail, browser security warnings appear, automations break, integrations stop, customers lose access, with a footer note 'and all it took was a missed date'. Below, a CERTIFICATE LIFECYCLE strip with seven equally weighted controls: inventory, ownership, expiration monitoring, alerts, renewal process, automation, and post-renewal testing.

Infrastructure Security

Certificate Expiration Is Still Taking Systems Down

An expired certificate is one of the simplest, most preventable outages, and it still keeps happening. The fix is not heroics on renewal day. It is treating certificates like production assets: a real inventory, a clear owner, monitored expirations, alerts, a renewal process, automation where possible, and post-renewal testing so the change does not break something downstream.

Read article

Back to all insights