On Mon, 7 Mar 2011 12:40:04 +0100
Paul Slootman wrote:
> The backups would have worked fine with the existing vault, apart from
> downloading all the files with changed metadata once -- just like you
> did by creating the new backup vault.
I'm just concerned about the meta data. Like I mentioned
On Mon, Mar 07, 2011 at 06:49:05PM +0100, Paul Slootman wrote:
> It's just that the phrase "new directory entry with different metadata"
> is so wrong :-)
Ah, but it is a true statement that hard link design doesn't
allow for multiple sources of meta data.
___
On Mon 07 Mar 2011, Dale Amon wrote:
> On Mon, Mar 07, 2011 at 12:47:23PM +0100, Paul Slootman wrote:
> > On Sun 06 Mar 2011, Dale Amon wrote:
> > >
> > > Oh futz. Hard links don't allow a new directory entry with different
> > > metadata. I had not thought that all the way through.
> >
> > I get
On Mon, Mar 07, 2011 at 12:47:23PM +0100, Paul Slootman wrote:
> On Sun 06 Mar 2011, Dale Amon wrote:
> >
> > Oh futz. Hard links don't allow a new directory entry with different
> > metadata. I had not thought that all the way through.
>
> I get a sense of misunderstanding here about how files,
On Sun 06 Mar 2011, Dale Amon wrote:
>
> Oh futz. Hard links don't allow a new directory entry with different
> metadata. I had not thought that all the way through.
I get a sense of misunderstanding here about how files, directories and
inodes really work, so I'll volunteer some info now :)
An
On Sun 06 Mar 2011, hanj wrote:
> I created a entirely new vault, and backups are working fine with that
> new backup vault.
The backups would have worked fine with the existing vault, apart from
downloading all the files with changed metadata once -- just like you
did by creating the new backup
Hi,
[file renames]
On Sunday 06 March 2011 17.50:44 Dale Amon wrote:
> It's sort of the deduplication problem... if btrfs really does
> solve that, it could be a very big win.
As I said, the chmod/chown case *should* be fine today. Deduplication in
other cases (file renames, but also similar/id
On Sun, Mar 06, 2011 at 01:28:29PM +0100, Paul Slootman wrote:
> Dirvish's mission is to keep a completely correct backup of the source
> tree. If attributes have changed, they may have been changed because
> things didn't work correctly before, so it's important to have the
> latest image reflect
On Sunday 06 March 2011 13.28:29 Paul Slootman wrote:
> Seems a bit on the assinine side to duplicate say, an
>
> > unchanged 100GB iso image, just because the user 'touch'd,
> > chmod'ed or chown'ed it. Really a rather serious waste of
> > resources.
There's no choice here: hardlinked files hav
On Sun, 6 Mar 2011 09:47:40 +
Jenny Hopkins wrote:
> Hanj - you've said this is out of the blue, but have there been
> absolutely no changes to your system at all? - upgrade, change to an
> nfs mount, any system changes like that?
Out of the blue. Backups on this box has been running for yea
On Sat 05 Mar 2011, Dale Amon wrote:
> On Sun, Mar 06, 2011 at 01:35:44AM +0100, Paul Slootman wrote:
> >
> > The owner is (has become?) different. Hence dirvish needs to retransmit
> > those files as the metadata is different.
>
> But if the contents has not changed, the actual transmittal
> sho
On 4 March 2011 23:00, hanj wrote:
> Hello All
>
> I've been backing up one of my linux servers for years. Last night out
> of the blue, it's thinking that my /home partition (which is a separate
> drive) needs to be completely backed up. It's very odd, I looked at the
> backups prior and only a f
On Sun, Mar 06, 2011 at 01:35:44AM +0100, Paul Slootman wrote:
> On Sat 05 Mar 2011, hanj wrote:
>
> > I did this and here is a partial output of some of the files:
> >
> > cd+ home/hanj/.audacious/.thumbs/
> > >f+ home/hanj/.audacious/.thumbs/Classic.png
>
> > The files on the a
On Sat 05 Mar 2011, hanj wrote:
> I did this and here is a partial output of some of the files:
>
> cd+ home/hanj/.audacious/.thumbs/
> >f+ home/hanj/.audacious/.thumbs/Classic.png
> The files on the actual server:
>
> drwxr-xr-x 2 hanj users 240 Apr 6 2007 .
> -rw-r--r-- 1 h
On Sat, 5 Mar 2011 12:49:42 +0100
Paul Slootman wrote:
> You can try running the rsync command as shown in the summary (or is it
> log...) with the -n -i options (dry run, and itemize changes) to show
> why it thinks files are out of date.
Hello Paul
I did this and here is a partial output of s
On Fri 04 Mar 2011, hanj wrote:
>
> I deleted the vault and re-ran it again, and I can confirm that it
> wants to backup the whole thing. Also, one directory from another drive
> on the same server is doing the same thing. Not sure what to do to
> address this problem. Is this a problem on the cli
16 matches
Mail list logo
