As an example, if you modify some documents on the source drive and/or on the destination, they will not be copied. The old files remain unchanged on the destination. Ignore existing: Do not copy files that are already exist on the source and destination drive, even if the file on the source is newer. If you accidentally delete a file or folder from the source but you have a copy on the destination, after this operation those files will be deleted from the destination. Files that were copied to the destination in an earlier backup but later deleted from the source will remain on the backup copy.ĭelete on destination: This is identical to the above option except the extra files that exist on the destination but not on the source will be deleted. ![]() So if you never edit the files on the destination, this option (no option selected) will keep all your files up to date. Extra files that are on the destination that do not exist on the source are left alone. All other files are copied to the destination even if the destination files are newer. No option selected: Files that are identical on the source and the destination are not copied. Note: The trailing slashes at the end of both paths.I set up two test directories one on the source and one on the destination and tested the options. rsync -avzlh -ignore-existing /sata1/home/ramya/ /tmp/home/ramya/ | tee /tmp/$(date+"%F_%R")-backup.log So the solution is to use entire directory name (instead of asterisk) as argument to rsync command. The asterisk will expand all files in the current working directory except the files whose name starts with a dot (hidden files). Thus, rsync never receives the hidden files as arguments. bash-3.2#du -h -x /sata1/home/ramyaġ2K /tmp/home/ramya/techglimpse/openvas.txtįrom the above output, I understood that the hidden files were not copied and it was due to “ *" (asterisk) used in the rsync command. To debug the issue, I used du command to check the size of each file inside the source and destination folders as shown below: By listing the files and comparing the file size. So where’s the remaining data? Let me explain how I fixed the issue. Lookout for the ‘asterisk’ in the above command (that was the issue and I’ll be explaining the reason below the fold) du command discrepancy findings:ĭu command output of the source directory (/sata1/home/ramya/): # du -chs /sata1/home/ramya/ĭu command output of the destination directory (/tmp/home/ramya): # du -chs /tmp/home/ramya/įrom the above snapshots, you can see that the source directory is of size 167GB and the copied directory is of size 1.4GB. ![]() As told earlier, I used rsync to copy the directory as shown below: usr/bin/rsync -avzlh /sata1/home/ramya/* /tmp/home/ramya/ | tee /tmp/$(date+"%F_%R")-backup.log ![]() Scenario: Let us assume – the old storage mount point is ‘/sata1/home/ramya’ and the new storage mount point is ‘/tmp/home/ramya’. Below is snapshot explaining the scenario. But to my surprise, the data to be copied was around 167GB and the copied data was of just 1.4GB! I used ‘du’ command to calculate the disk size of source and destination folders and ensured that ‘du’ is not showing erratic results by following this tutorial – how to fix erratic disk usage statistics from du. ![]() The operation completed successfully without throwing any warning/error. I used rsync command to copy a particular user directory from one storage device to another.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |