cp -al, rsync
Various source changes would likely change some metadata in the old
sets. And it doesn't handle those pesky multiple link-dests.
overhead ... dirvish ... find ... etc
In C, in rsync, would be a more efficient general solution than any
particular bolt on equivalent.
option
Of
On Mon, 2010-02-08 at 09:30 -0500, grarpamp wrote:
cp -al, rsync
Various source changes would likely change some metadata in the old
sets.
Yep. See my request for a --no-tweak-hlinked option to avoid such
attribute tweaking issues:
https://bugzilla.samba.org/show_bug.cgi?id=4561
And it
Rsync would then need an extra option to enable it to report such
deleted files, because I sure don't need that nor do I need the extra
overhead that encurs.
I agree.
If deletion reporting is to become part of rsync (when invoked with the dest
option --link-dest option), then I would
cp -al, rsync
Various source changes would likely change some metadata in the old
sets.
Yep. See my request for a --no-tweak-hlinked option to avoid such
https://bugzilla.samba.org/show_bug.cgi?id=4561
This is interesting. Though it would have more uses than being just
another bolt on
On Sun, 7 Feb 2010, grarpamp wrote:
[[Benjamin R. Haskell wrote:]]
And, it's a slow process on my machine
Ramdisk is good for such empty file tests.
Good tip.
And you can blow it away in a second by simply nuking the core.
Instead of waiting for rm to grind the rust off your
On Sun, 07 Feb 2010 13:00:04 -0600, rsync-requ...@lists.samba.org wrote:
It's simply that rsync _can_ be made to do all this in one invocation.
Since it has to look at and consider all three of source, prior and current
anyways, it makes sense to enhance it with this printing capability.
I
On Fri 05 Feb 2010, grarpamp wrote:
Beware when using rsync --link-dest, --delete -Haxi !!!
Files that are present in the previous datedir/hier/run but will
not be present in the currently to be made datedir/hier/run,
[because they are no longer present in the source hier],
DO NOT show up
Files that are present in the previous datedir/hier/run but will
not be present in the currently to be made datedir/hier/run,
[because they are no longer present in the source hier],
DO NOT show up in the output of rsync -i as deletions.
As they shouldn't, as they're not deleted.
Sure,
Grarpamp wrote:
Yes, hardlinks save data block duplication... yet on filesystems with
millions
of files / long pathnames, just the directory entries alone can take up
gigs
per image. Multiply that out by frequency and it can quickly add up.
Huh?
--
Please use reply-all for most replies to
On Sat, 6 Feb 2010, Tony Abernethy wrote:
Grarpamp wrote:
Yes, hardlinks save data block duplication... yet on filesystems
with millions of files / long pathnames, just the directory entries
alone can take up gigs per image. Multiply that out by frequency and
it can quickly add up.
Huh?
See now? :-)
That seemed excessive to me, too. In a short test it seems accurate.
Yep, it is.
And, it's a slow process on my machine
Ramdisk is good for such empty file tests. And you can blow it away
in a second by simply nuking the core. Instead of waiting for rm to
grind the rust
On Fri 05 Feb 2010, Andrei_r20 wrote:
So what I am thinking of doing now is:
The fist backup is done to an empty destination. Than, each following backup
will be done to a freshly created empty dir with current date as name but
with --link-dest option pointing at the previous (latest)
The fist backup is done to an empty destination. Than, each following backup
will be done to a freshly created empty dir with current date as name but
with --link-dest option pointing at the previous (latest) backup directory.
LBackup also allows you quickly setup this kind of rotating hard
Beware when using rsync --link-dest, --delete -Haxi !!!
Files that are present in the previous datedir/hier/run but will
not be present in the currently to be made datedir/hier/run,
[because they are no longer present in the source hier],
DO NOT show up in the output of rsync -i as deletions.
14 matches
Mail list logo
