02-14-2018, 10:50 PM
(This post was last modified: 02-14-2018, 11:48 PM by Sprintrdriver.)
Hi forum.
I've just set up an rsync command to make backup from home folder (ext4) to a mounted fat partition (Veracrypt volume), and I ran into a issue that rsync choose to make backup from most files - instead of make backup of only the files where date is different. That is it seems to make extra backup of files that seemingly/should have the same date stamp in source as in destination folder.
The second thing is that rsync does creates numerous empty folders into subfolders of backup directory (/rsync_backup/).
The question I have - what causes this behavior?
Extended info or comments that I believe may be relevant:
- I have run rsync before some times on Ubuntu, but never went ahead and asked in any forum. Seems that this happens only the first time that rsync is run towards a destination directory. Next time I run rsync - if it behave the same as before - same command would work as expected, and only those files that is truly changed will copy (and backup is made from old version).
- Before I ran rsync towards the new FAT volume, I had an old FAT volume that was filled up. So I made a new bigger volume - still fat file system because of access within windows - and copied all files from the old fat volume to the new fat volume.
- Is there known issues with rsync handling of fat file stamp?
The full rsync command:
The /home/user2/c2/ is the fat volume mounted by Veracrypt. Current directory is where I copy files from, ~/Documents$
[edit]
After searching around the web, I found that there is a time-stamp issue in fact when using rsync between ext/fat file systems. So I changed to:
That raise another issue - the backup-dir is located within the destination folder and was not a good idea. Is there any other options other than move it elsewhere - so that rsync doesn't deletes this particular folder?
I've just set up an rsync command to make backup from home folder (ext4) to a mounted fat partition (Veracrypt volume), and I ran into a issue that rsync choose to make backup from most files - instead of make backup of only the files where date is different. That is it seems to make extra backup of files that seemingly/should have the same date stamp in source as in destination folder.
The second thing is that rsync does creates numerous empty folders into subfolders of backup directory (/rsync_backup/).
The question I have - what causes this behavior?
Extended info or comments that I believe may be relevant:
- I have run rsync before some times on Ubuntu, but never went ahead and asked in any forum. Seems that this happens only the first time that rsync is run towards a destination directory. Next time I run rsync - if it behave the same as before - same command would work as expected, and only those files that is truly changed will copy (and backup is made from old version).
- Before I ran rsync towards the new FAT volume, I had an old FAT volume that was filled up. So I made a new bigger volume - still fat file system because of access within windows - and copied all files from the old fat volume to the new fat volume.
- Is there known issues with rsync handling of fat file stamp?
The full rsync command:
Code:
rsync -tarv -b --backup-dir="/home/user2/c2/rsync_backup/$(date +"%Y-%m-%d_%H-%M")" ./ "/home/user2/c2"
The /home/user2/c2/ is the fat volume mounted by Veracrypt. Current directory is where I copy files from, ~/Documents$
[edit]
After searching around the web, I found that there is a time-stamp issue in fact when using rsync between ext/fat file systems. So I changed to:
Code:
rsync -trv --size-only --delete-before -b --backup-dir="/home/user2/c2/rsync_backup/$(date +"%Y-%m-%d_%H-%M")" ./ "/home/user2/c2"
That raise another issue - the backup-dir is located within the destination folder and was not a good idea. Is there any other options other than move it elsewhere - so that rsync doesn't deletes this particular folder?
I won't let an old, but fully functional computer die just because some company tell me that they won't make no more security updates to their OS. Thanks Linux