Dear Paul, I am glad of your complete reply. It is nice that you freely exchange about the program, giving your impressiosn and some background.
So, to say, I have been trying your command, and implemented it into my code for sync my folder pendrive of my $HOME to the real pendrive. it seems to works completely well, i.e. LINUX => FAT so I find it working, and cool, and it is du -hs checking always perfectly matching. two ideas: - a sort of du -hs could be implemented to check bytes levels if all is righly copied on the program rsync, if not && / || could let user to output an error or success message. This could be involqued by --check-du or whatever. However, the main point of my concern: --no-p --no-o --no-g the switches are highly complicated for the newbie or ubuntu user that simply want to backup its linux pendrive to fat of pendrive. It could eb simplified by createing a new simple command that is taking those swtiches . --no-p --no-o --no-g such as rsync -avr source target* --force-fat* A new though.. I am daily using your powerful command to backup my /home to /backup this is avoid raid and virus or wahtever raid issues that could occurs. However I am concerned by a thing. I absolutely never checked it has been done well since many month, since your reply, if the backup is performing well ... well, this is living on the edges, and relaying on a simple command could be dangerous if a crash occurs. Since it is the server (you have one too) it is lot of relevant data, and it might be good that admin gets notify if something went wrong during teh backup... what do you think ? I know that tehre is potential for admins for makign rsync backups even more secured, or it could automatically do some : echo "error $(date)" | mutt -s "rsync" `cat /root/.emailroot` to warn, but well , you know that email from root over mutt or gmail or inteernet is dangerous / security Well, some ideas, - man, I really have to take time to check whether this crontabed rsync is performing well,... maybe one day before a possible crash happen ... All the best, and wishing you nice autumn Yellow On Wed, Sep 8, 2010 at 9:09 PM, Paul Slootman <p...@debian.org> wrote: > On Wed 08 Sep 2010, yellow protoss wrote: > > > > The issue is that the rsync is not copying any files, simply due to > > permissions. I would say that it shall be importnat that the files are > > surely copied however the fault permissions. cp -au works, however the > > permisisons small issue. > > If you tell rsync to preserve permissions, and it cannot, how is it to > proceed? Try with --no-p --no-o --no-g > > > Well my concern is as follows,a nd is similar issue: > > I daily do rely on backing up about 6 TB of data on a server, simply > based > > on rsync. > > And you back that up on a VFAT filesystem? Good luck :-) > > This is my backup server: > > /dev/mapper/vg0-data2 > 7.1T 7.1T 51G 100% /data2 > /dev/mapper/vg0-data1 > 7.2T 7.1T 19G 100% /data1 > > All done with rsync, no problems. I use ext4, very recommended. > > > Rsync could be more reliable to avoid any user to loose data during > copying, > > and ensure a secured way to backup different systems : pendrive, hdd of > > windows xp <==> linux , and in making sure that permissions are not a > > relevant issue causing for users believe that data are safely backed > up... > > You need to use a filesystem that can preserve all the attributes that > you want to backup. VFAT is _not_ such a filesystem. rsync is doing the > right thing by giving an error when you ask it to do something that is > impossible. cp -a doesn't warn you (apparently, I haven't checked). > Maybe using tar to backup the files to a single tar file on the VFAT > filesystem may be better for your purpose, although you are then missing > out on rsync features when making a second backup etc. > If you don't need compatibility with Microsoft-based systems, you could > reformat the stick to ext4 or so. > > Note also for preserving owner/group you need to run as root; it looks > like you are not (your ~$ prompt suggests this). > > > Paul >
