## Intro HDFS replication is not a backup. Replication protects against a single block or DataNode loss, but it does not prevent or undo accidental deletions, logical corruption, ransomware, application bugs, human error, or complete site failures. Snapshots give point-in-time recovery within the same cluster and namespace, but they are not offsite, not immutable by default, and do not replace a comprehensive backup and disaster recovery (DR) strategy. This handbook gives Hadoop administrators, Big Data engineers, platform architects, and DevOps teams a production-ready playbook for HDFS backup and restore: what to protect, how to back it up, how to restore fast, and how to verify that it actually works. ## Key differences you must know

Topic	What it is	What it protects	Limits
HDFS replication	Block-level copies across DataNodes	Single-node or disk failures	Not protection from deletes/corruption/site loss
HDFS snapshots	Point-in-time, per-directory metadata refs	Accidental deletion, quick rollback	Same cluster; snapshot deletion risks; no offsite
Full backup	Copy everything	Baseline for recovery	Time/cost; large window
Incremental backup	Copy changes since last backup	Efficient deltas	Chain length complicates restore
Differential backup	Changes since last full	Faster restore than incremental chains	Larger than incremental
DistCp	Parallel inter-cluster copy	Large data moves/DR/migrations	Metadata nuances; needs bandwidth
Cross-cluster replication	Scheduled DistCp/Ranger policies	DR, migrations, multi-site data	Lag; eventual consistency
High Availability (HA)	Redundant NameNodes + QJM	Service continuity on NN failure	Not a backup; no point-in-time recovery
Disaster Recovery (DR)	Recover service in another site/cluster	Site failures, ransomware	Requires planning, testing, runbooks

## HDFS architecture you back up ASCII overview: +----------------------+ | Clients | +----------+-----------+ | RPC / WebHDFS | +-----------v------------+ | NameNode(s) | | FSImage + EditLog | +-----+------------+-----+ | | QJM (JournalNodes) | | | +------------v----+ +---v--------------------------+ | JournalNode x3 | | DataNodes (blocks) | +-----------------+ +------------------------------+ - NameNode: holds filesystem metadata in FSImage (checkpoint) + EditLog (recent ops). In HA, Active/Standby share edits via Quorum Journal Manager (QJM) on JournalNodes. - DataNodes: store HDFS blocks with replication. - Checkpoint/Backup Node: legacy roles that can create FSImage checkpoints; most modern clusters rely on SecondaryNameNode or automated checkpoints and QJM. - Critical commands: saveNamespace (flush FSImage) and rollEdits (rotate EditLog). Metadata flow: Client op -> EditLog append -> in-memory NN state -> (periodic) saveNamespace -> FSImage checkpoint ## Core backup methods and how to use them ### 1) NameNode metadata backups (must-have) - How it works: Periodically persist FSImage and EditLog, copy off-cluster. - Commands: - Flush a safe image: hdfs dfsadmin -safemode enter && hdfs namenode -saveNamespace && hdfs dfsadmin -safemode leave - Rotate edits: hdfs namenode -rollEdits - Validate: hdfs oiv -p XML -i fsimage_0000... -o fsimage.xml and hdfs oev -i edits_0000... -o edits.xml - Advantages: Fast restore of namespace; independent of data block copies. - Limits: Does not back up blocks; schedule consistently. - When: Always, daily or more often for high churn; before large maintenance. - Verify restore: Start a lab NameNode with restored FSImage/edits, enter safemode, run hdfs fsck / -files -blocks , compare namespace counts with hdfs dfsadmin -report . ### 2) HDFS snapshots (per-directory PIT recovery) - How: Enable on directory and create snapshots. - hdfs dfs -mkdir /data/finance - hdfs dfsadmin -allowSnapshot /data/finance - hdfs dfs -createSnapshot /data/finance snap_2024_10_01 - Pros: Instant, space-efficient, great for oops-deletes. - Cons: Same cluster; users with snapshot delete perms can remove them; not ransomware-safe. - Use when: Fast rollbacks, dev/test guards, short-term protection. - Verify: Delete a test file, hdfs dfs -cp /data/finance/.snapshot/snap_2024_10_01/file /data/finance/ . Snapshot workflow: Enable -> Create snapshot -> Changes accumulate -> Restore by cp from .snapshot ### 3) DistCp (large-scale copy and DR backbone) - How: Parallel MapReduce copy between filesystems/clusters. - Example intra-DC: hadoop distcp -m 50 -update -delete hdfs://src-cluster/data hdfs://dst-cluster/data - To object storage: hadoop distcp -m 100 -bandwidth 200 -update hdfs:///data s3a://backup-bucket/data/ - Pros: Parallel, resumable, scalable; ideal for hundreds of TB+. - Cons: Needs bandwidth and capacity; metadata (ACLs/XAttrs) require flags. - Prefer DistCp over copyToLocal/copyFromLocal for inter-cluster or very large transfers; local copies bottleneck on a single client. - Verify: Re-run with -update -delete -diff (if using snapshots), compare counts hdfs dfs -count -q , and sample checksum hdfs dfs -checksum . DistCp between clusters: [hdfs://A] ===parallel===> [hdfs://B] or [s3a://bucket] ### 4) Full, incremental, differential backups - Full: First complete copy (DistCp to DR cluster or object store). Verify with fsck , -count , and sample checksums. - Incremental: Use -update with snapshot diff: hadoop distcp -m 100 -update -diff snap_t0 snap_t1 hdfs://src/data hdfs://dst/data . - Differential: Copy changes since last full by diffing from full snapshot. - Pros: Control over RPO/RTO; network/cost efficiency. - Cons: Chains add complexity; snapshot hygiene required. - When: Large datasets, periodic DR syncs, cost-optimized cloud backups. ### 5) Object storage backups (S3, MinIO, Azure Blob, GCS) - How: Use s3a:// , abfs:// , gs:// , or MinIO S3 endpoints with DistCp. - Pros: Offsite, durable, cheap at scale; enables immutable storage (Object Lock/WORM). - Cons: Latency; eventual consistency (improving); egress costs. - Verify: Versioned bucket listing, random file restore tests to a sandbox HDFS. ### 6) NAS/NFS backups - How: Export HDFS via NFS gateway or copy critical exports to enterprise NAS snapshots. - Pros: Integrates with enterprise backup tools; quick file access. - Cons: Gateway bottlenecks; POSIX mismatches. - Use when: Small critical subsets need traditional backup workflows. ### 7) Cross-cluster replication and HA vs DR - HA: Active/Standby NameNodes with QJM for uptime inside a site. - DR: Asynchronous copies (DistCp) to a remote cluster. Plan for DNS/app failover and data lag. - Federation: Multiple namespaces for scale; each namespace needs its own backup/DR plan. Enterprise DR architecture: Primary HDFS (HA) --DistCp--> DR HDFS (HA) --Export--> Object Store (immutable) | | Clients Failover Runbooks ## Real production scenarios and what to do - Accidental directory deletion: Restore from latest snapshot via cp from .snapshot . If missing, pull from DR/object backup. - Restoring from snapshot: hdfs dfs -cp /path/.snapshot/snap_t0/* /path/ then validate with application checks. - Recover a failed NameNode: Replace node, restore FSImage/edits into dfs.namenode.name.dir , start in safemode, hdfs fsck , then exit safemode. In HA, hdfs namenode -bootstrapStandby for the standby. - Corrupted metadata: Use last good FSImage + edits; validate with oiv/oev ; discard bad edits if necessary, acknowledging data loss window. - Losing one DataNode: HDFS self-heals. Monitor hdfs dfsadmin -report ; run hdfs balancer -threshold 10 after recovery. - Losing multiple DataNodes: If replication under RF, blocks become missing. Restore affected paths from DR/object backups. - Migrating to a new cluster: Baseline DistCp full -> freeze writes -> incremental DistCp -> cutover. - Ransomware: Lock down snapshot delete perms; restore from immutable object backups (S3 Object Lock) and rotate cluster credentials. - Restore a dev environment: Subset restore of tables/paths to non-prod with masking. - Entire datacenter failure: Promote DR cluster, update service endpoints, backfill from last sync, execute runbook. ## Performance and optimization - DistCp tuning: Increase -m mappers, set -bandwidth to avoid WAN saturation, co-locate map slots with storage. - Compression: Use server-side bucket compression or store Parquet/ORC to reduce transfer size. - Scheduling: Run large backups in off-peak windows; throttle using YARN queues. - Petabyte scale: Partition by top-level directories, run multiple DistCp jobs; use snapshot diffs to limit deltas. ## Security and compliance - Kerberos: Ensure keytabs for DistCp jobs and service users; renew tickets via kinit in Airflow/NiFi. - Authorization: Preserve ACLs/XAttrs with -p acl,xa,ctime in DistCp when needed. - Encryption at rest: HDFS Encryption Zones for regulated data; ensure KMS backups and key rotation procedures. - Encryption in transit: TLS for RPC and DataTransferProtocol; secure JournalNodes. - Immutable backups: Use S3 Object Lock (compliance mode), bucket versioning, and limited delete rights. - Auditing: Capture DistCp logs, Ranger/Atlas audits, and checksum manifests for evidence. ## Operational checklists - Backup preparation: - Define RPO/RTO, classify datasets, pick targets (DR HDFS, object store), size bandwidth. - Enable snapshots where needed; secure snapshot deletion. - Backup verification: - Post-run counts, random checksums, sample file opens, metadata (ACL) spot checks. - Restore preparation: - Maintain runbooks, sandbox cluster, and IaC for DR infra; pre-stage credentials. - Post-restore validation: - hdfs fsck / -files -blocks , application smoke tests, Hive/Spark table repair. - DR testing: - Quarterly failover exercise; measure RTO/RPO; fix gaps. - Security audit: - Review KMS backups, key rotations, snapshot policies, IAM least privilege. - Production readiness: - Monitor jobs in Airflow/Cloudera Manager/Ambari; alert on lag/fail; capacity forecasts. ## Comparison quick-look - Replication vs Backup: - Replication: availability of blocks; no rollback. Backup: recovery to a prior state/site. - Snapshot vs Backup: - Snapshot: in-cluster PIT. Backup: off-cluster, long-term, immutable. - Snapshot vs DistCp: - Snapshot: create PIT. DistCp: move data; can use snapshot diffs to optimize. - Full vs Incremental: - Full: simplest restore; heavy copies. Incremental: efficient; chain complexity. - Local vs Remote: - Local: fast but fragile. Remote: resilient; adds latency and cost. - HDFS vs Object Storage: - HDFS: strong throughput, compute locality. Object: durable, elastic, cheap for cold. - HA vs DR: - HA: no downtime on NN loss. DR: survive site loss and corruption. - DistCp vs copyToLocal/copyFromLocal: - DistCp: distributed, parallel, resilient. copy*Local: single-node, lab use only. ## Commands you will actually run - Health: hdfs dfsadmin -report , hdfs fsck / -files -blocks -locations - Snapshots: hdfs dfsadmin -allowSnapshot /path ; hdfs dfs -createSnapshot /path snap1 ; hdfs dfs -deleteSnapshot /path snap1 - Metadata: hdfs namenode -saveNamespace ; hdfs namenode -rollEdits ; hdfs oiv ; hdfs oev - DistCp: hadoop distcp -m 80 -update -delete -bandwidth 300 -p acl,xa hdfs://A/data hdfs://B/data - Balance: hdfs balancer -threshold 10 ## Complete backup and restore workflows Backup: [Create snapshots] -> [DistCp full/incs] -> [Copy FSImage/edits] -> [Store to DR & Object (immutable)] Restore: [Provision NN] -> [Restore FSImage/edits] -> [Mount data target] -> [DistCp back or rehydrate] -> [fsck + app tests] ## Integrations in the enterprise stack - Apache Spark/Hive: Quiesce or use snapshot-based incremental windows; run MSCK REPAIR TABLE or ALTER TABLE RECOVER PARTITIONS after restore. - Apache Ozone: Separate replication/backup plan if used as storage; DistCp between Ozone/HCFS via connectors. - Apache Ranger/Atlas: Backup policies/metadata separately; restore before data access. - Apache NiFi/Airflow: Schedule DistCp and validations; manage credentials and retries. - MinIO/Object Storage: Use versioned, locked buckets; monitor lifecycle policies. - Kubernetes: Package backup jobs as CronJobs with Kerberos sidecars. - Cloudera Manager/Ambari: Monitor HDFS health, schedule saveNamespace , track DistCp via YARN. ## Common production mistakes to avoid - Assuming replication replaces backups. - Not backing up FSImage/EditLog and KMS keys. - Never testing restores or DR failover. - Keeping backups on the same cluster. - Ignoring growth and WAN bandwidth. - Skipping integrity validation and ACL/XAttr preservation. - Undocumented, unpracticed recovery runbooks. - Relying only on snapshots without offsite copies. ## Conclusion A resilient HDFS backup and DR program combines four pillars: consistent NameNode metadata backups, efficient data movement (DistCp full + incremental), secure offsite immutable storage, and rigorously tested restore runbooks. Start with RPO/RTO targets, automate with Airflow or CI, monitor every job, and rehearse quarterly. When incidents happen, you will restore quickly and safely—because you already did it yesterday in practice.