HDFS is very robust, so in any case if HDFS corrupts we can use the following two ways provided to the user in order to recover data given below:

1. HDFS FSCK (For Data Node)
2. Namenode - recover

DataNode:-

Fsck is an offline process which examines on-disk structures and usually offers to fix them if they are damaged. HDFS has its own FSCK command, which you can access by running “HDFS FSCK.” HDFS FSCK determines which files contain corrupt blocks, and gives you options about how to fix them.

HDFS FSCK command operates only data, not on metadata. This difference is irrelevant on the local filesystem because data and metadata are stored in the same place. However, for HDFS, metadata is stored on the NameNode, whereas data is stored on the DataNodes.

NameNode:-

When properly configured, HDFS is robust, because it stores multiple copies of everything. The administrator has the capability to recover a partial or corrupted edit log. This new functionality is called manual NameNode recovery. Similar to FSCK, NameNode recovery is an offline process. An administrator can run NameNode recovery to recover a corrupted edit log.

Sart the NameNode with the -recover flag to activate recovery mode, like:

./bin/hadoop namenode -recover

Though Manual Recovery is the Best Choice. If there is another valid copy of the edit log somewhere else, it is preferable to use that copy rather than trying to recover the corrupted copy. This is a case where High availability can help a lot. If there is a standby NameNode ready to take over, there should be no need to recover the edit log on the primary. When there is no other copy of the edit log available, Manual recovery is a good choice.