Data Backup seems simple, but not simple.

Data Backup seems simple, but not simple-Linux general technology-Linux technology and application information. The following is a detailed description. [I = s] This post was last edited by okzokz123 at, January 5 ,.

"Backup" is an inevitable problem for people to enter the computer era. in addition to personal data and other aspects of production and life, backup is required if data security is involved.
Backup:
Backup not only requires data, but also ensures data security, so it is not common to copy, paste, or cp.
In windows, goodsync or some other backup tools can be used.
In linux, you can use rsync to make the backup directory exactly the same as the source directory:
Rsync-auv -- delete -- progress/PATH/backup file or directory/PATH // this way, you can back up the file to the directory PATH and instantly see the backup process, if there is a mistake, return it on the terminal. If you want to compress data during transmission, use the parameter-Z. if you want to ensure data consistency during transmission, use the parameter-c. For example:
Rsync-uva-c -- delete -- progress/PATH/backup file or directory/PATH // this way, the backup data can be completely consistent with the original data to prevent malicious tampering (such as virus infection) or data inconsistency caused by disk damage, but if there is a large amount of data validation, it will certainly slow down the backup speed.

Additional reading:
1. as mentioned above, the rsync and-c parameters can be used to verify data integrity, but the backup speed may be slowed down. In fact, you can also back up data before using other methods for data verification, such as md5sum shaxsun (x = 1,256,512); rsync only faithfully synchronizes data, data integrity is generally caused by virus infection or disk damage (including file system damage) and other hardware problems such as memory damage, which is not related to rsync. The following describes how to verify the data.
First, cd to the backup source directory, recursively create a hash document with all the data in the backup directory; during verification, this file must be copied to the same level Directory of the backup destination directory for verification.
Find-type f-print0 | xargs-0 md5sum> |/path/md5 // md5 this file name can be specified arbitrarily
Verification: md5sum-c md5 // if there is no accident, the terminal is returned after a large piece of "OK". if there is any discrepancy, an error message is returned.
Md5sum-c md5>/path/hash // output the validation result to a file named hash. you can query the file to find the files with specific errors, avoid failing to see which files are not completely synchronized due to quick screen flushing.
Cat/path/hash | grep failed. // The specific file with an error is queried. If no error exists, the file is directly returned to the terminal.

2. because the backup usually uses interfaces such as USB or esata for data transmission, data integrity is inevitable due to machine failure, it is common that the write cache and device usage cannot be removed and the brute force removal method is adopted. In this way, the data is not written, but the current data is incomplete. the damage to the file system causes greater losses.
In windows, you can use the Microsoft toolkit with a sync.exe tool to perform write-back. if you still cannot remove the tool, you need to save the other work and log out of the system before removing the device.
In linux: of course, there will also be issues with writing cache and the inability to safely remove devices, but the solution is very simple. sync (write back), and then umount unmount the Mount directory to directly remove it.

3. check the file system frequently.
Windows: using chkdsk or graphics (take XP as an example) open Disk Management-right-click a partition you want to check-properties-tools-start Check-Select (automatically repair file system errors and scan and try to recover bad sectors)-then start to check errors
Linux: umount unmount a mount point (required to enable the fsck to exclusively occupy the device to avoid data errors caused by reading and writing other programs during detection) then, perform fsck based on the file system type of the backup disk:
Generally, the mbr disk can use sudo fdisk-l to query the device number. The gpt disk can use parted/dev/sdx (x = B, c, d ...) then press p to query, or other tools.
Sudo fsck-t ext4/dev/sdb1 // Check the disk of an ext4 file system recognized as/dev/sdb1 by a device.
Sudo ntfsfix/dev/sdb1 // check the device of an ntfs partition

Conclusion: a complete backup process can be completed only after the entire process from the backup of the inserted device to the verification data is completed. I am always having problems with synchronization data because of memory corruption. Fortunately, I understand that data verification is required to ensure data security. otherwise, backup will become useless. It is best to check if there is no problem. if there is a problem, consider the factors mentioned above.