Hello,
i was trying backup from my virtual machine (openxen) using rsync , after backup i used du -sh at destination and source , unbelievably amount of disk usage at destination was double time of amount of data at source, i checked , for duplication data , nothing found ,here is my situation
source :
linux lenny , ext3 ,
destination:
linux os , ext4 (tested with ext3)
command :
rsync -a -v --delete -e ssh /mbox root@IP:/mbox
also used
scp -r /mbox root@IP:/mbox

i used ::: du -sh ::: df -h ::: for disk usage

Any Idea....
Thanks

Without more detail I can only guess, but perhaps the source had one or more sparse files. By default, rsync does not try to preserve sparseness (use the "-S" or "--sparse" option to do that). I don't see any option in scp to preserve sparseness.

Hi,
What details do u need rknichols?
i dont know what is going on , may be linux bug , the where i'm working used linux lenny 5.0.4 for most their projects, when i check some servers i see "du -sh" result has different value from"df -h" , it makes a big problem,

Running du and df on a filesystem will very often yield different results. The du command walks through the directory tree and reports/sums the sizes of what it finds. The df command directly queries the filesystem and reports the number of blocks in use. Why would these be different? The most common cause is files that have been deleted from the directory tree but are still held open by some process(es). That would cause df to report higher usage than what du can see.

The other common cause is files that exist on the filesystem but are hidden under an active mount point. Let's say you decide to move /home from the root filesystem to a separate partition. You copy the current contents of /home to the new partition, and then mount the new partition on /home. All looks well, and /home now has lots of space from the new, presumably larger, partition. The catch is that you never deleted the files from the root filesystem. They still occupy space there, but "du --one-file-system" won't see them on the root partition while the new /home is mounted there.

I don't know whether either of these applies to your situation. Initially you reported different results for "du -sh" at the source and destination, which suggests a completely different issue. You would need to look at the output from "du --max-depth=N", with gradually increasing values for N, to try to see where the differences occur.

Post the exact command you used and include where you ran it from.

Du you have same file systems, block size etc on all your systems involved?
Block size usage and file size are not exactly the same. If you have a small text file with e.g. 20 bytes, it would still use a full block (e.g. 4096 bytes).

^ this

And I noticed you didn't have -H set in your rsync command, which means any hard links on the source will be duplicated on the destination, resulting in double, triple, quadruple, etc. the disk usage (depending on how many hard links you had on the source).

Hi,
source location is /mbox and it has only mail in it's directories , there is no hard link there , the strange thing is the size of folder inside and outside of that , different size , for example :
du -sh folder == 60M
cd folder
du -dh * ==> 40M

Thanks suicidaleggroll

There are 2 possibilities. Either (a) the directory file itself is huge (unlikely, unless you have tens of thousands of users), or (b) there are dotfiles in that directory (the expansion of "*" will not include any filenames that begin with ".").