Article catalog
Principle of file deletion in Linux operating system
What should we do if we delete files or data by mistake?
Experimental ideas:
1 . Add new hard disk
2. Partition
3. Use the new partition table to format and mount:
4. Copy some test files, delete them, and then demonstrate recovery:
5. Install extundelet to restore files

1. Upload extundelete to linux:
2. Unzip and install extundelte
3. Attempt recovery
   Method 1: restore through inode node
   Method 2: recover by file name
   Method 3: restore a directory, such as all files in directory a:
   Method 4: restore all files
   Summary: backing up data is king

It's impossible to delete the database. It's impossible to delete the database in this life. Can you delete the root?
Satisfy you:

[root@zmgaosh ~]# rm -rf /
rm: stay"/" Recursive operations are dangerous
rm: use --no-preserve-root Option skip safe mode
[root@zmgaosh ~]# 

>   Write before:

Today, we don't delete the database. Let's talk about how to recover the accidentally deleted files?

 - [ ] can
 - [ ] No
 
Which one do you choose? The answer is yes. We have to start with the principle

### Principle of file deletion in Linux operating system

Linux The file system consists of three parts: file name, inode，block

zmedu.txt          -->inode              --> block
 file name         Storing file metadata information       Real data storage

> Files are stored on the hard disk. The smallest storage unit of the hard disk is called "sector"( Sector). Each sector stores 512 bytes (equivalent to 0.5KB). 
> 
> When the operating system reads the hard disk, it will not read sectors one by one, which is too inefficient. Instead, it reads multiple sectors continuously at one time, that is, one "block" at one time( block). This "block" composed of multiple sectors is the smallest unit of file access. The size of "block", the most common is 4 KB，Eight consecutive sector Form a block. 
> 
> The file data is stored in "blocks". Obviously, we must also find a place to store the "meta information" of the file, such as the creator of the file, the creation date of the file, the size of the file, and so on. This area for storing file meta information is called inode，The Chinese translation is"Index node". 
> 
> Any data we access is found first inode,Then according to inode To find the location of the corresponding hard disk. without inode No, there is no way to find the data on the hard disk.

this inode Where is the number?

```bash
[root@zmgaosh ~]# ls -i b.txt
262170 b.txt   

From the previous example, we can see that the inode number of b.txt is 262170

-The metadata contained in inode is as follows:

• Size the number of bytes of the file
• Uid User ID of the owner of the file
• Group ID of Gid file
• There are three timestamps for the read, write and execute permissions of Access files:
  Change refers to the time when the inode was last changed
  Modify refers to the time when the file content was last changed
  Access is the last time a file was opened
• Links is the number of links, that is, how many file names point to this inode
• Location of Inode file data block
• Blocks number of blocks
• IO Blocks block size
• Device number

We can also view inode information through stat

[root@zmgaosh ~]# stat b.txt
  File:"b.txt"
  Size: 25              Block: 8          IO Blocks: 4096 normal files
 Equipment: fd01h/64769d      Inode: 262170      Hard link: 1
 jurisdiction:(0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Recent visit: 2020-06-19 20:55:39.327737431 +0800
 Recent changes: 2020-06-19 20:55:34.924697772 +0800
 Recent changes: 2020-06-19 20:55:34.926697790 +0800
 Created on:-

Knocking on the blackboard: in the Linux operating system, the file name is just a nickname for easy identification of inode number. The operating system identifies the file through inode number, not the file name.

As a user, we open a file. The internal process of the system is as follows:

1. The system finds the inode number corresponding to this file name
2. Get inode information through inode number
3. According to the inode information, find the block where the file data is located and read out the data

In the same Linux system, file deletion is controlled by the number of links. Deletion means that the link from the file name to inode is deleted, but the block data block of the file on the disk is not deleted.

Therefore, if we want to recover, we only need to recover the corresponding inode node number to recover the data, but the premise is that the data is not overwritten.
So the question comes: what are the first things we should do after deleting files by mistake?

• Resign and run away
• Unmount the file partition you want to restore
• The partition to be recovered is mounted as read-only

What should we do if we delete files or data by mistake?

Experimental ideas:

1. Add a new hard disk to the virtual machine (this hard disk is used to create data, delete data and restore data simulation)
2. Partition, format, and mount the new hard disk sdb
3. Create data on the new disk, and then delete the data
4. Recover data

1 . Add new hard disk

2. Partition

[root@gaosh63 /]# fdisk /dev/sdb  #Partition sdb

Command (m for help): n   #Create a new partition
Command action
   e   extended
   p   primary partition (1-4)
#Create a primary partition
Selected partition 1

Last cylinder, +cylinders or +size{K,M,G} (1428-2610, default 2610): +1G  #Specify partition size

Command (m for help): w  #preservation

[root@gaosh63 ~]#reboot
or
[ root@gaosh63 ~]#PartX - A / dev / SDB # get new partition table

3. Use the new partition table to format and mount:

[root@gaosh63 /]# mkdir /tmp/sdb     #Create mount point
[root@gaosh63 ~]# mkfs.ext4 /dev/sb1    #format
[root@gaosh63 ~]# mount /dev/sdb1 /tmp/sdb/   #mount 

4. Copy some test files, delete them, and then demonstrate recovery:

[root@gaosh63 ~]# cp /etc/passwd /tmp/sdb1/
[root@gaosh63 ~]# cp /etc/hosts /tmp/sdb/
[root@gaosh63 ~]# echo aaa > a.txt
[root@gaosh63 ~]# mkdir -p /tmp/sdb/a/b/c
[root@gaosh63 ~]# cp a.txt /tmp/sdb/a/
[root@gaosh63 ~]# cp a.txt /tmp/sdb/a/b/
[root@gaosh63 ~]# touch /tmp/sdb/a/b/text.txt   #Create an empty file to see if the empty file can be recovered

Start deleting files:

[root@gaosh63 ~]# cd /tmp/sdb/
[root@gaosh63 sdb]# ls
a  hosts  lost+found  passwd
[root@gaosh63 sdb]# rm -rf a hosts passwd

After deleting the file by mistake, we need to uninstall the partition or mount it in read-only mode at the first time:

[root@localhost ~]#cd /root
[root@localhost ~]# umount /tmp/sdb

5. Install extundelet to restore files

1) Upload extundelete to linux:

2) Unzip and install extundelte

[root@gaosh63 extundelete-0.2.4]# tar jxvf extundelete-0.2.4.tar.bz2 
[root@gaosh63 ~]# cd extundelete-0.2.4
[root@gaosh63]# yum install e2fsprogs-devel
[root@gaosh63 extundelete-0.2.4]# ./configure   #Check the system installation environment

[root@gaosh63 extundelete-0.2.4]# make  -j 4  #compile
[root@gaosh63 extundelete-0.2.4]# make install  #install

3) Attempt recovery

Method 1: restore through inode node
Method 2: recover by file name
Method 3: restore a directory, such as all files in directory a:
Method 4: restore all files

[root@gaosh63 ~]# mkdir test  #Create a directory to store the recovered data
[root@gaosh63 ~]# cd test/

First, we need to find the deleted file name through the inode node:

[root@gaosh63 test]# extundelete /dev/sdb1  --inode 2
.                                                2
lost+found                                        11
passwd                                            12             Deleted
hosts                                             13             Deleted
a                                                 7313           Deleted

Then we began to recover:

Method 1: restore through inode node

[root@gaosh63 test]# extundelete /dev/sdb1 --restore-inode 12
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 9 groups loaded.
Loading journal descriptors ... 63 descriptors loaded.
[root@gaosh63 test]# ls 
RECOVERED_FILES

See if it is the same as the source file:

[root@gaosh63 test]# diff /etc/passwd RECOVERED_FILES/file.12  # No output indicates that the recovery is successful, but the file name is different

Method 2: recover by file name

[root@gaosh63 test]# extundelete /dev/sdb1 --restore-file passwd
[root@gaosh63 test]# diff /etc/passwd RECOVERED_FILES/passwd  # There is no output, the description is the same, and the file name is the same this time

Method 3: restore a directory, such as all files in directory a:

[

root@gaosh63 test]# extundelete /dev/sdb1 --restore-directory a
[root@localhost ~]# tree RECOVERED_FILES/
RECOVERED_FILES/
├── a
│   ├── a.txt
│   └── b
│       └── a.txt
├── file.12
└── hosts

The following is the original directory structure:

├── a.txt
└── b
    ├── a.txt
    ├── c
└── kong.tx

As can be seen from the above figure, empty files cannot be recovered.

Method 4: restore all files

[root@gaosh63 test]# extundelete /dev/sdb1 --restore-all

Summary: backing up data is king

How do you deal with data loss caused by data deletion (generally referring to physical file damage or rm induced deletion)?

• If there is a backup, you can use mysqldump+binlog to achieve full recovery and xtrabackup to achieve incremental recovery
• There is no backup, but master-slave synchronization or dual master structure is done. The slave database can be promoted to the master database to recover data
• If your company does not have a backup or a database, you can recover the data through extundelete.

Remember: any remedial measure is an accident and does not appear to be too big. The operation and maintenance on the big should be to standardize the online and offline operation and maintenance to ensure that there are no operation and Maintenance accidents.

This article is from ID: Internet old Xin more content is concerned about the official account of the "geek operation and maintenance home".