Re: speaking of rsync

Matt Giwer <jull43@xxxxxxxxxxxxxxx> writes:

Unruh wrote:
Matt Giwer <jull43@xxxxxxxxxxxxxxx> writes:
....
Regret the delay that does almost what I wanted. The addition of -u does
exactly what I wanted.

rsync -avxu --delete --progress /old/ /new

It's a backup. Why would there be newer versions of the file on the
backup than on the original? Where do they come from?

They come from me changing them manually. After changing them I want a backup

You changed them manually on the backup? Not on the original? Why would
you do that?

reflecting my changes with an exact copy. Doesn't sound like something all

That sounds like you changed the original. Fine, rsync will make sure
that all of those changes are also made on the backup.


that important but I found all the dupes added up when I was converting say
.flac to .mp3 and the deleting the former.

??? That is a complete change of files. rsync will get those without the
-u, unless you are making those changes on the backup and not the
originals. If that is what you are doing, then -u is apprpriate (
especially with the --delete option)



Someone said I was not clear which is not unusual. My need was to be able to
manually reorganize an existing directory and back it up for an exact copy.
Say I would make a cp -R copy of a directory and them later modify the
original directory simply moving a file to another directory. Doing another cp
operation would leave the file in the old directory and add a copy to the
other directory. The same with changing file names. Old and new name would
appear in the backup directory.

In rsync the --delete removes the file from the old directory and eliminates
the old name while adding the new name. The -u is added as without it rsync
recopies all the old files even if unchanged. -u only copies those which have
been changed --updated.

Complete nonesense. rsync does not recopy old files if they are the same
on the backup as on the original ( you may see their names flashing
past, but that just means that they are being checked, not copied, as
you will notice when a 100GB file takes less than a second to update)

Also it sounds as if your backup computer has time problems In the
first instance it looks at the date and size of the file to determine
whether or not to check that the file has changed.

What -u does is if the timestamp on the backup is later than the
timestamp on the original, then it is not checked. Sounds like you have
time problems on your machines. Run chrony or ntp to keep the times on
the various machines accurate.

I have no idea what rsync you are using nor what options you may invoke as a
default. I am using the one that came with Fedora 10. I used the switches I
posted. I only report what happened when I used it.

Perhaps we are not communicating. I ran the test twice without the -u. Both
times it recopied the source file. The man page says -u prevents that and
only updates rationally. I tried it with the -u and it worked. I kept the -v
in all three tests and that is what it reported it was doing.

No it did not.
The way rsync as a default works is to compare the times on the original
and backup and compares the sizes of the two files. If both are the same
( to within 2 sec I believe) that file is skipped entirely. If they are
not the same, then rsync runs a sequential MD4 over the two files to
discover which parts of the two files have have changed. If nothing has
changed, nothing is transfered. If something has changed only that
something is transfered. However, even if nothing is transfered the file
name is listed as being processed, not transferred on the -v option.

Ie, just because a filename is listed under -v does NOT mean that
anything is transferred. It just means that file is checked.



I am not looking to claim I know more than anyone else. Anyone who wants can
try it as originally posted and as I suggest, that is only with and without
-u. It is not like it matters or that it can hurt anyone to try the -u.

Since I use rsync to make backups every night with 100GB of data, I have
some familiarity with how it works. IF you are making backups, -u is a
bad idea. If the clocks are out on the two systems so that the times on
the backups are slightly later, then rsync will not replace the file
even if it is totally different. Ie, -u will destroy your backups.
It WILL hurt.



.

Relevant Pages

  • Re: Mp3 Books
    ... but as a *backup* to protect the originals, I have had great success with the sellers at eBay. ... takes he about 6 minutes to rip a CD so that I can listen to it on my MP3 player when I go to bed. ... Some sellers take the time to do that. ...
    (alt.fan.harry-potter)
  • Re: Getting my piccies off the iPhone
    ... databases that most of the data on the mac is stored on, ... Moving it - generally speaking I wouldn't want to move something out of a backup, as then there is a change of breaking things. ... it is a folder containing a load of date stamped folders from when it did backups with files that either link to the originals or are the originals. ...
    (uk.comp.sys.mac)
  • Re: maintaining picture file properties post enhancement
    ... > aperture, ISO, date of shot, etc. ... freebie to backup and restore the EXIF info. ... originals on CD-Rs. ... Picture It! ...
    (microsoft.public.windowsxp.photos)
  • Re: ALL NEW MP3 SEARCH ENGINE WWW.MINITUNES.ORG
    ... The intent is for someone ... So let's say you made a backup copy of something. ... You gotta sell anything you can to make your rent this month. ... gonna have to destroy those before you sell these originals. ...
    (rec.music.progressive)
  • Re: [opensuse] Suggestions for backup software?
    ... be something capable of bridging DVDs for a total backup, and probably CDs for incremental backup. ... At home I have an old file server running 10.0 and all you need is rsync that is already installed on your system. ... The way I set up rsync is to set up a primary script that calls rsync which then reads a second file to get a list of directories to back up. ...
    (SuSE)