rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] restore old backups fails with gzip error -


From: Ben Escoto
Subject: Re: [rdiff-backup-users] restore old backups fails with gzip error -
Date: Sun, 7 Aug 2005 11:23:55 -0700

>>>>> dean gaudet <address@hidden>
>>>>> wrote the following on Sat, 6 Aug 2005 23:16:09 -0700 (PDT)

> > > I think (A) is far more desirable.
> > 
> > Oops you are right.  Dean I saw below that you found the problem, does
> > it still need fixing?  
> 
> nope i didn't figure out the right way to fix it... istr i couldn't
> figure out how to get the right path to the right bit of the code
> ... without a global variable kludge :)

After looking at the code a bit I think I realize why it's set up this
way, and I'm not sure there is anything to fix anymore.  (Except the
error messages.)

So to recap, here I think were the options:

A) When restoring, put tempfiles in the volume to be written.
B) Put tempfiles where environment says (try TMPDIR, TEMP, TMP, etc.)

At first glance it seemed that Hunter was right, we should do A.
After all, when backing up tempfiles are put in the volume we backup
to.  However, there are 3 problems with A:

1)  The tempfiles are written by librsync by applying diffs.  Thus
    they must be local to the backup repository!  (It might be
    possible to work around this, but not with any semblance of
    bandwidth efficiency.)

2)  Sometimes we will want to "restore" without actually writing.  For
    instance, when doing a full-file compare the temp files would have
    to go to TMPDIR or similar; there is no other place for them.

3)  Backups do not require any free space on the source directory.  If
    any tempfiles were to go to the volume to be written when
    restoring, it would lead to the pathological situation of being
    able to backup a directory but unable to restore it.

So for these reasons I think B) is the proper behavior, and the way
it's supposed to work now.


-- 
Ben Escoto




reply via email to

[Prev in Thread] Current Thread [Next in Thread]