rsync alternative?

[Andy Ruhl]

I've been using rsync a while, and recently I've needed it to replace
some files. I never noticed that it does not preserve BSD file flags.

I use flags, so I need to preserve them.

I'm using rsync to backup a 300 gig filesystem that's about 90% used
and has about 75000 files. It's backing up to another locally attached
disk which is 500 gigs. I use dump to send a subset of the data that I
consider most important off the machine and somewhere else.

I suppose I could write a script as part of the rsync process that
sets flags on the other filesystem to ensure they stay there, but that
seems kind of clumsy.

What is a good alternative that reasonably preserves rsync's efficiency?

I did notice that there is a project on the NetBSD projects page for a
BSD licensed version of rsync. Would be nice if it could preserve
flags...

Thanks.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stefan Schumacher]

Post by Andy Ruhl
I've been using rsync a while, and recently I've needed it to replace
some files. I never noticed that it does not preserve BSD file flags.
I use flags, so I need to preserve them.
I'm using rsync to backup a 300 gig filesystem that's about 90% used
and has about 75000 files. It's backing up to another locally attached
disk which is 500 gigs. I use dump to send a subset of the data that I
consider most important off the machine and somewhere else.
I suppose I could write a script as part of the rsync process that
sets flags on the other filesystem to ensure they stay there, but that
seems kind of clumsy.
What is a good alternative that reasonably preserves rsync's efficiency?

I use rsync and rdiff-backup for backups, but only for homedirs, which do not use file flags.
However, mtree(8) can be used to generate a fingerprint of a filesystem, including flags.
Mtree can also be used to update a filesystem structure to match that fingerprint.
So you could use mtree(8) to make a fingerprint of the original file and apply that fingerprint to the backup dir.
But test if it works - and if it works, pleas send me copy of that skript, so I can add it to my backup guide ;-)





--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Herb Peyerl]

Post by Andy Ruhl
I suppose I could write a script as part of the rsync process that
sets flags on the other filesystem to ensure they stay there, but that
seems kind of clumsy.

Only slightly less clumsy would be to have cron run an 'mtree' on the
filesystem and have that rsync'd as well.

The world needs a better rsync. I concur.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Herb Peyerl

Post by Andy Ruhl
I suppose I could write a script as part of the rsync process that
sets flags on the other filesystem to ensure they stay there, but that
seems kind of clumsy.

Only slightly less clumsy would be to have cron run an 'mtree' on the
filesystem and have that rsync'd as well.
The world needs a better rsync. I concur.

I'm not sure if this is the time or place, but is the statement really
"the world needs a better rsync" or "BSD people need to make their own
rsync"?

There are other fileystems out there that have attributes that rsync
probably doesn't handle, and I'm not sure it makes sense to blame
rsync for it.

Maybe the best solution would be for someone in the BSD community to
come up with a simple, easily available code patch for rsync that can
be applied via pkgsrc? Or simply fork the entire thing and rename it
bsdrsync or something...

I'm not a developer, unfortunately, or I'd look into it more.

As for fixing the flags after the fact, I suppose there are various
ways of doing it, but I think it would require one to stat every file
in the filesystem looking for the attributes that are desired to be
preserved, right? Not very efficient on large filesystems, but do-able
I suppose.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Herb Peyerl]

Post by Andy Ruhl

Post by Herb Peyerl
The world needs a better rsync. I concur.

I'm not sure if this is the time or place, but is the statement really
"the world needs a better rsync" or "BSD people need to make their own
rsync"?

My statement does not refer only to the problem of filesystem
attributes. I have been using rsync in production for years and in
various instances, been having problems with rsync processes going
off the rails midway through a transfer (from one disk to another on
the same host) and going zombie... I've been trying to debug the
problem for years but sadly, I can't reproduce it and it's persisted
across many releases of rsync. Last I looked (a couple years ago),
there was an open bug on the problem... It still happens to me and I
keep dutifully upgrading rsync hoping it will go away.

It seems to most happen on filesystems with lots of tiny files.

Anyway, rsync has the feature set I want, but not the reliability I
look for, and I lack the time to fix the problem.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stefan 'Kaishakunin' Schumacher]

Post by Andy Ruhl
Maybe the best solution would be for someone in the BSD community to
come up with a simple, easily available code patch for rsync that can
be applied via pkgsrc? Or simply fork the entire thing and rename it
bsdrsync or something...

According to the rsync mailing list archives, there is a patch for a
--flags option, submitted by a FreeBSD hacker.

http://rsync.samba.org/ftp/unpacked/rsync/patches/flags.diff