6/17/2023 0 Comments Silverstack shows no files to copy![]() The same file can take up a different amount of disk space, if for example the filesystems blocksizes differ. du shows the amount of disk space used by a file, not the size of the file. Now for the second part, why is there a size difference with du. Those were not "transferred" but just re-created. The difference here should be equal to the total amount of directories, symnlinks, other special files. Number of files transferred: is the count of normal files that were updated via rsync’s delta-transfer algorithm, which does not include created dirs, symlinks, etc. ![]() Number of files: is the count of all "files" (in the generic sense), which includes directories, symlinks, etc. First, why is there a difference between "Number of files" and "Number of files transferred". ** Always ensure your backup volumes are mounted with the exact same file system mount options as the source AND turn on full logging with rsync for later grep analysis to search for any errors in long file listings! ** dev/sda1 /mnt/wd750 ext4 nobarrier,noatime,user_xattr 0 2Īfter performing another full rsync for the 3rd time, I decided to let a file count run all night on my full home folder and rsync'd backup: find /home/hholtmann/ -type f | wc find /mnt/wd750/c51/home/hholtmann/ -type f | wc -l # I HAD to add the ,user_xattr option to match my home volume ![]() rsync was skipping all my dropbox path files.Įnds up my /home volume was mounted with the user_xattr ext4 mount option in the /etc/fstab file: /dev/mapper/vg1-lv_home /home ext4 nobarrier,noatime,user_xattr 0 2 ![]() What I saw was errors from rsync stating that it could NOT write any of my DROPBOX dir files to the destination due to the "extended attributes" on the files. I DID find some files that were NOT rsync'd by adding more verbose output to rsync by adding -vv to rsync and running again. I just assumed every file would take the same space in terms of du numbers. I was just surprised by this byte difference given that both volumes are ext4 with default block sizes. The selected answer below explains for the byte count difference and my incorrect expectation of the rsync summary data. What am I missing? Or is this a sign I'm ready for management!?! Why such unexpected results? A file is a file. HOWEVER: NO FILE COUNT difference between the same source and destination sub-dirs find /home/hholtmann/proj/ -type f -follow | wc find /mnt/wd750/c51/home/hholtmann/proj/ -type f -follow | wc -l Just to compare an important project sub-dir in my home after rsync:īyte difference between a source and destination sub-dir using du du -cs /home/hholtmann/proj/ġ8992676 du -cs /media/wd750/c51/home/hholtmann/proj/ġ9006768 /mnt/wd750/c51/home/hholtmann/proj/ Total transferred file size: 487.41G bytes Here is the command line I used as root rsync -ah -progress -stats /home/hholtmann /mnt/wd750/c51/home/ -vĬaptured summary output from rsync Number of files: 4857743 I was logged in as root and used rsync to backup my /home/hholtmann/* directory to a spare backup drive in /mnt/wd750/c51/home/ I want to backup my FULL home folder to an external disk so I can fully WIPE and reformat my system and then restore my home from this rsync'd backup, but I am concerned I am missing significant data files. Does anyone know common reasons for such a large deficit difference in the number of files transferred when backing up my LARGE home directory using rsync on a Ubuntu 10.04 LTS setup? The machine is stable and all volumes are clean ext4 - no errors from fsck.ext4.
0 Comments
Leave a Reply. |