Certificate
Digital Certificate
A signed digital identity that binds a name or system to a public key.
In everyday business: Browsers, VPNs and servers use certificates to prove who they are and encrypt connections.
DATA PROTECTION
Backup, Snapshot and Replication Playbook
Separate fast rollback, independent backup and disaster recovery so the client knows exactly what each copy protects against.
Book 4 | Chapter 6
Chapter opening
Chapter 6 moves from the course overview into backup, snapshot and replication. The aim is not to memorise product menus or commands. The reader should understand what problem the technology solves, how it fits into the wider storage technical textbook, what normal operation looks like, and how to prove the result in the field.
The previous chapter introduced storage performance troubleshooting playbook. This chapter continues the sequence by focusing on backup, snapshot and replication playbook, so the reader can connect the architecture to a more specific operational problem.
Learning objectives
- Explain the main purpose of Backup, Snapshot and Replication in plain language.
- Identify the components that must work together for the service to operate.
- Use evidence to separate a design problem from a configuration or physical fault.
- Describe the business impact of a failure and the evidence required for handover.
Why this matters in a real company
For a company, the question is simple: if a server fails or files are encrypted or deleted, how much work is lost and how long before people can work again? This chapter turns that business question into a technical recovery design.
Course: Storage Technical Textbook
PLAIN ENGLISH
Technical terms used in this chapter
You do not need to memorise the jargon first. Understand what each term does and why somebody running a company would care about it.
Replication
Replication
The process of copying data or VM state to another system or location.
In everyday business: It can shorten recovery time after a server or site failure, but copied corruption can also replicate.
Snapshot
Snapshot
A point-in-time storage or VM state used for short-term rollback depending on the platform.
In everyday business: It can quickly undo a bad change, but it is not automatically an independent backup.
Volume
Container Volume
Persistent storage kept separately from the short-lived container filesystem.
In everyday business: Company data can survive when an application container is replaced.
Backup
Backup
An independent recoverable copy of data or system state.
In everyday business: It is the safety net for deletion, corruption, ransomware, hardware loss or major mistakes.
DNS
Domain Name System
The service that translates names into IP addresses and helps Windows domain clients find services.
In everyday business: People and applications can use names instead of remembering network numbers.
NAT
Network Address Translation
A router or firewall function that changes IP addressing as traffic crosses a boundary.
In everyday business: Many private office devices can share one public Internet address.
PAT
Port Address Translation
A form of NAT that lets many internal connections share one public address by tracking transport ports.
In everyday business: Hundreds of users can browse the Internet through one public IPv4 address.
BUSINESS TRANSLATION
What this means outside the server room
This topic matters because technical infrastructure exists to support everyday business operations. Understanding the purpose makes it easier to choose the right design and justify the cost.
DNS
What it means: DNS translates names into IP addresses and also helps many business services locate each other.
In normal business language: It is the company phonebook for systems. Staff type a name such as fileserver or portal instead of remembering a number.
Why the decision matters: Good DNS design reduces configuration mistakes and is especially important for Windows domains, cloud integrations and internal applications.
Backup
What it means: A backup is an independent recoverable copy of data or system state.
In normal business language: Think of it as having a duplicate of important company records stored safely away from the live filing cabinet.
Why the decision matters: A backup only counts if it can be restored. Test recovery, not just backup completion.
Snapshot
What it means: A snapshot is a point-in-time state of a storage volume or VM on the same platform.
In normal business language: It is like a quick undo point inside the same office. Very useful for rolling back a mistake, but not enough if the whole storage system is lost.
Why the decision matters: Use snapshots for fast rollback, but keep independent backups for real disaster recovery.
Replication
What it means: Replication copies data or VM state to another system or location.
In normal business language: It is like keeping a second live copy of the filing room at another branch. It can reduce recovery time, but bad changes can also be copied.
Why the decision matters: Replication improves availability and recovery speed, but it does not replace retention and backup.
Firewall
What it means: A firewall controls which network connections are allowed between users, systems and external networks.
In normal business language: It is a security checkpoint between parts of the company network. It should allow legitimate work while blocking unwanted access.
Why the decision matters: Firewall rules should describe real business flows such as 'staff may reach accounting on HTTPS', not unexplained broad permits.
NAT
What it means: NAT changes IP addresses as traffic crosses a network boundary.
In normal business language: It is similar to a company switchboard: many internal extensions can share one public number.
Why the decision matters: NAT helps with address use and publishing services, but it is not a substitute for firewall security.
6.1 Snapshot
A snapshot is a point-in-time state on a storage platform. It can make rollback very fast, but it normally depends on the source storage system and therefore should not be treated as the only copy of important data.
Backup
A backup should be independently recoverable from the production system. The important proof is a restore test, not a green "backup complete" icon.
Replication
Replication moves data or snapshots to another system/site. It improves recovery options but can also replicate corruption or unwanted changes depending on retention and implementation.
RPO and RTO
- RPO: how much recent data loss the business can tolerate.
- RTO: how long the service can remain unavailable.
These are business requirements. They should drive backup frequency, retention and recovery architecture.
Integrity checks
Synology documents a Hyper Backup "Restore Only" state when backup integrity is corrupted and recommends investigating hardware, shutdown and storage consistency. This illustrates why backup integrity must be monitored, not assumed.
Restore drill
- Select a representative file and a representative application dataset.
- Restore to an alternate test location.
- Verify content opens and application consistency is acceptable.
- Record restore time and steps.
- Update the runbook.
Client benefit
The client knows which failures can be rolled back quickly, which require backup restore, and what happens if the primary storage system is completely lost.
6.2 Retention is part of recovery design
Keep enough restore points to survive the time between corruption starting and being discovered. A fast ransomware event and a slow unnoticed database corruption are different retention problems.
Off-site and offline considerations
At least one recovery path should survive loss of the production site or credentials where the business requirement demands it. Whether that is offline, immutable, cloud or another site depends on the platform and risk model.
Application consistency
Crash-consistent snapshots may be acceptable for some workloads but not all applications. Databases and transactional systems can require application-aware quiescing or backup agents. Follow the application vendor's supported method.
Restore documentation
Document not only where backups are stored but how to restore when the original server, NAS or credentials are unavailable. Recovery instructions should survive the failure they are meant to solve.
6.3 3-2-1 as a planning concept
A common data-protection planning idea is multiple copies on different media or systems with at least one copy separated from the primary site or failure domain. The exact implementation depends on business requirements, regulations and platform capabilities.
Immutability
Where supported, immutable or write-protected backup copies can reduce the risk that compromised administrator credentials delete every recovery point. Verify how retention locking works and who can change it.
Encryption keys
Encrypted backups are only recoverable if the required keys, passwords or certificates survive the incident. Store recovery secrets in an approved secure location separate from the backup system itself.
Bandwidth planning for replication
Initial seeding and daily change rate can exceed WAN capacity. Measure changed data volume and available replication window. Compression and deduplication may help on supported platforms, but plan from measured transfer behaviour.
Recovery order
Document which systems must return first: identity/DNS, firewall/VPN, storage, application databases, file services and user-facing applications. Recovery sequencing matters because later services may depend on earlier infrastructure.
WORKED BUSINESS SCENARIO
Scenario: the backup job is green, but can the company recover?
Nightly backup reports all show success. A user deletes a critical folder and later the main storage system fails. Nobody has tested restoring the application or locating the encryption keys.
What the chapter teaches us: A successful backup job is not the same as a proven recovery process. The business needs known restore points, documented credentials, recovery order and measured restore time.
Think it through
- How much data can the company afford to lose?
- How long can the service remain unavailable?
- What evidence proves a backup is actually usable?
PRACTICAL WORK
Hands-on lab
Use repadmin and DNS checks in a lab with two DCs. Record replication partners and successful status, then compare after a controlled DNS misconfiguration.
Troubleshooting exercise
One DC has new users that another DC does not. Check DNS, time, connectivity, replication status and event logs before forcing replication.
Chapter field checklist
- I can explain the subject without relying only on acronyms.
- I can draw or describe the main traffic, storage, power or service path.
- I know what normal operation should look like.
- I know which logs, counters or test results prove the result.
- I can explain the business impact if this component fails.
- I would document the final configuration and evidence at handover.
Chapter summary
Backup, Snapshot and Replication Playbook should now be understood as a business service with a technical implementation, not simply a collection of commands or product names. The important habit is to know the purpose, understand the dependencies, measure the result and document what was proven.
END OF CHAPTER
Review questions
- Explain the subject in plain language to a business owner.
- List the main dependencies that must be healthy before this service can work.
- Describe one realistic failure and the first three pieces of evidence you would collect.
- Explain what should be documented at handover.
A good answer should explain the reason, not only repeat a product name or command.
Technical references
Use the current project specification and the exact product documentation for the installed equipment. These references support the technical principles used in this guide.