Backup and disaster recovery in Hadoop - Step-by-Step Execution

Concept Flow - Backup and disaster recovery

Start: Data in Hadoop Cluster

↓

Create Backup Snapshot

↓

Store Backup in Safe Location

↓

Monitor Cluster Health

↓

Disaster Occurs?

No→Continue Operations

Yes↓

Restore Data from Backup

↓

Verify Data Integrity

↓

Resume Normal Operations

This flow shows how Hadoop data is backed up, monitored, and restored after a disaster to keep data safe and operations running.

Execution Sample

Hadoop

hdfs dfsadmin -saveNamespace
hdfs dfs -createSnapshot /data backup1
hdfs dfs -cp /data/.snapshot/backup1/* /backup_location/
# Disaster happens
hdfs dfs -rm -r /data/*
hdfs dfs -cp /backup_location/* /data/
hdfs dfsadmin -saveNamespace

This code creates a snapshot backup of Hadoop data, copies it to a safe location, simulates data loss, and restores data from the backup.

Execution Table

Step	Command	Action	Result
1	hdfs dfsadmin -saveNamespace	Save current namespace metadata	Namespace saved successfully
2	hdfs dfs -createSnapshot /data backup1	Create snapshot named 'backup1' of /data	Snapshot 'backup1' created
3	hdfs dfs -cp /data/.snapshot/backup1/* /backup_location/	Copy snapshot to backup location	Snapshot copied to /backup_location/
4	# Disaster happens	Disaster occurs	Disaster initiated
5	hdfs dfs -rm -r /data/*	Remove contents of /data directory	/data contents removed
6	hdfs dfs -cp /backup_location/* /data/	Copy backup snapshot back to /data	Backup restored to /data
7	hdfs dfsadmin -saveNamespace	Save namespace metadata after restore	Namespace saved successfully

💡 Data restored from backup, namespace restored, system ready for normal operations

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	After Step 6	Final
/data content	Original data present	Snapshot created (data unchanged)	Backup copied (data unchanged)	Deleted (empty)	Restored from backup	Restored data present
Namespace	Current metadata	Saved metadata	Saved metadata	Saved metadata	Saved metadata	Saved metadata

Key Moments - 3 Insights

Why do we create a snapshot before copying data to backup location?

Creating a snapshot freezes the data state at a point in time, ensuring the backup is consistent and not affected by ongoing changes. See execution_table step 2 and 3.

What happens if we try to restore data without saving the namespace first?

Namespace metadata might be out of sync causing inconsistencies. Saving namespace (step 1) and saving it again (step 7) keeps metadata aligned with data.

Why do we delete /data before restoring from backup?

Deleting /data simulates data loss or disaster. It ensures the restore process actually replaces lost data. See execution_table step 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result after step 3?

A Snapshot copied to /backup_location/

B Namespace saved successfully

C Snapshot 'backup1' created

D Backup restored to /data

💡 Hint

Check the 'Result' column for step 3 in execution_table

At which step is the /data directory deleted?

A Step 4

B Step 5

C Step 6

D Step 7

💡 Hint

Look for the command 'hdfs dfs -rm -r /data' in execution_table

If we skip saving the namespace at step 1, what might happen?

A Backup snapshot will fail

B Data will not be deleted

C Namespace metadata may be inconsistent after restore

D Snapshot cannot be copied

💡 Hint

Refer to key_moments about namespace saving and restoring

Concept Snapshot

Backup and disaster recovery in Hadoop:
- Use 'hdfs dfs -createSnapshot' to freeze data state
- Copy snapshot to safe backup location
- Save namespace metadata with 'hdfs dfsadmin -saveNamespace'
- On disaster, delete lost data and restore from backup
- Save namespace metadata again ('hdfs dfsadmin -saveNamespace') to keep system consistent
- Verify data integrity before resuming operations

Full Transcript

This visual execution shows how Hadoop handles backup and disaster recovery. First, the system saves the namespace metadata to keep track of the file system state. Then, it creates a snapshot of the data directory to capture a consistent copy. This snapshot is copied to a backup location for safekeeping. When a disaster occurs, such as data loss, the contents of the original data directory are deleted to simulate the loss. The backup snapshot is then copied back to the original location to restore the data. Finally, the namespace metadata is saved again ('hdfs dfsadmin -saveNamespace') to ensure the file system metadata matches the restored data. This process helps keep Hadoop data safe and recoverable.

Practice

1. What is the main purpose of backup in Hadoop's disaster recovery?

easy

A. To delete old data automatically

B. To save copies of data to prevent loss

C. To speed up data processing

D. To encrypt data for security

Solution

1. Step 1: Understand backup purpose

   Backup means saving copies of data so it can be recovered if lost.

2. Step 2: Match with options

   Only To save copies of data to prevent loss describes saving copies to prevent data loss.

3. Final Answer:

   To save copies of data to prevent loss -> Option B

4. Quick Check:

   Backup = Save copies [OK]

Hint: Backup means saving data copies to avoid loss [OK]

Common Mistakes:

• Confusing backup with data processing speed
• Thinking backup deletes data
• Mixing backup with encryption

2. Which Hadoop command is used to copy files from HDFS to local for backup?

easy

A. hdfs dfs -get

B. hdfs dfs -ls

C. hdfs dfs -rm

D. hdfs dfs -put

Solution

1. Step 1: Identify command to copy from HDFS to local

   The command hdfs dfs -get copies files from HDFS to local filesystem.

2. Step 2: Check other commands

   -put copies local to HDFS, -rm removes files, -ls lists files.

3. Final Answer:

   hdfs dfs -get -> Option A

4. Quick Check:

   Copy HDFS to local = -get [OK]

Hint: Use -get to copy from HDFS to local [OK]

Common Mistakes:

• Using -put instead of -get
• Confusing -rm with copy commands
• Thinking -ls copies files

3. What will be the output of this command if the source file does not exist?
hdfs dfs -cp /data/file1.txt /backup/file1.txt

medium

A. cp: `/data/file1.txt`: No such file or directory

B. File copied successfully

C. Backup created with empty file

D. Command runs silently without error

Solution

1. Step 1: Understand the cp command behavior

   The hdfs dfs -cp command copies files within HDFS. If the source file does not exist, it throws an error.

2. Step 2: Match error message

   The error message for missing source file is "No such file or directory" as in cp: `/data/file1.txt`: No such file or directory.

3. Final Answer:

   cp: `/data/file1.txt`: No such file or directory -> Option A

4. Quick Check:

   Missing source file = error message [OK]

Hint: Missing source file causes 'No such file' error [OK]

Common Mistakes:

• Assuming silent success
• Expecting empty file creation
• Confusing error with copy success

4. Identify the error in this backup command:
hdfs dfs -copyToLocal /backup/data.txt /local/backup/

medium

A. The command should be -copyFromLocal to backup

B. The destination path should be HDFS, not local

C. The command is correct as is

D. The source path should be local, not HDFS

Solution

1. Step 1: Understand -copyToLocal command

   This command copies files from HDFS to local filesystem, useful for backup.

2. Step 2: Check source and destination paths

   Source is HDFS (/backup/data.txt), destination is local (/local/backup/), which matches command purpose.

3. Final Answer:

   The command is correct as is -> Option C

4. Quick Check:

   copyToLocal copies HDFS to local [OK]

Hint: copyToLocal copies from HDFS to local correctly [OK]

Common Mistakes:

• Confusing copyToLocal with copyFromLocal
• Swapping source and destination paths
• Thinking backup requires copyFromLocal

5. You want to create a disaster recovery plan that backs up daily changes in Hadoop data to a remote cluster. Which approach is best?

hard

A. Use hdfs dfs -rm to remove data after backup

B. Manually copy files with hdfs dfs -cp on local machine

C. Delete old backups and keep only latest file in HDFS

D. Use hdfs dfs -distcp to copy changed files to remote cluster daily

Solution

1. Step 1: Understand disaster recovery needs

   Disaster recovery requires copying data safely to a remote cluster regularly.

2. Step 2: Evaluate commands for remote copying

   hdfs dfs -distcp is designed for efficient distributed copying between clusters, ideal for daily backups.

3. Step 3: Check other options

   Manual copy is error-prone and slow; deleting backups or removing data is risky.

4. Final Answer:

   Use hdfs dfs -distcp to copy changed files to remote cluster daily -> Option D

5. Quick Check:

   distcp = best for remote backup [OK]

Hint: Use distcp for efficient remote cluster backup [OK]

Common Mistakes:

• Using local copy commands for remote backup
• Deleting backups too early
• Confusing remove command with backup