On 02/24 11:09 , Les Mikesell wrote:
> > That means there is no meaningful way of deleting an older
> > backup, as the parent files may be lost, rendering future links useless?
>
> On unix filesystems, the contents are not removed until the last link is
> deleted and no process has the file open
On 24/02/07, Jason B <[EMAIL PROTECTED]> wrote:
> Incidentally, unrelated, but something that's been bugging me for a while:
> subsequent full backups hardlink to older ones that have the true copy of the
> file, correct? That means there is no meaningful way of deleting an older
> backup, as the p
Jason B wrote:
>> 3.) Rsync(d) full backups go to more trouble to determine what has changed,
>> meaning they're more expensive in terms of CPU time and disk I/O, but
>> they'll catch changes incrementals may have missed. That means they're
>> vital every now and then, supposing you wa
Jason B wrote:
> close to
> the same way as an incremental, except it's more useful, so to say?
>
> Incidentally, unrelated, but something that's been bugging me for a while:
> subsequent full backups hardlink to older ones that have the true copy of the
> file, correct? That means there is no
Hiya,
> Jason Hughes explained how to incrementally transfer such a structure using
> $Conf{BackupFilesExclude}. The important thing is that you need successful
Well, I'm glad to say the $Conf{BackupFilesExclude} method worked fine. I had
to do it quite a few times (did about 10GB at a time), so
Hi,
Jason B wrote on 20.02.2007 at 20:28:59 [Re[2]: [BackupPC-users] Backing up
large directories times out with signal=ALRM or PIPE]:
> > [...] $Conf{ClientTimeout} will need to be at least 72000 [...]
>
> I see. I must've been misunderstanding the meaning of that settin
Nils Breunese (Lemonbit) wrote:
> Les Mikesell wrote:
>
>>> Although the ALRM and PIPE signals are probably technically correct
>>> it might be clearer to use different terms/explanations in the
>>> interface. I have the feeling not everyone understands these signals.
>>
>> man signal
>> will sh
Les Mikesell wrote:
Although the ALRM and PIPE signals are probably technically
correct it might be clearer to use different terms/explanations in
the interface. I have the feeling not everyone understands these
signals.
man signal
will show all the possibilities. SIGPIPE isn't very clea
Nils Breunese (Lemonbit) wrote:
>>> Apologies for the relatively long email, but I figure it's better to
>>> give too much information than not enough. I've run into a bit of
>>> difficulty backing up a large directory tree that has me not being
>>> able to do a successful backup in over a month n
Les Mikesell wrote:
Apologies for the relatively long email, but I figure it's better to
give too much information than not enough. I've run into a bit of
difficulty backing up a large directory tree that has me not being
able to do a successful backup in over a month now. I'm attempting to
back
Hi,
Jason B wrote on 20.02.2007 at 21:28:43 [[BackupPC-users] Backing up large
directories times out with signal=ALRM or PIPE]:
> I've run into a bit of
> difficulty backing up a large directory tree that has me not being
> able to do a successful backup in over a month now. I&#
Jason B wrote:
> However, the transfer always times out with signal=ALRM.
>
[...]
> Somewhat unrelated, but of all these attempts, it hasn't ever kept a
> partial - so it transfers the files, fails, and removes them. I have
> one partial from 3 weeks ago that was miraculously kept, so it keeps
>
Jason B wrote:
>
> Apologies for the relatively long email, but I figure it's better to
> give too much information than not enough. I've run into a bit of
> difficulty backing up a large directory tree that has me not being
> able to do a successful backup in over a month now. I'm attempting to
>
Hi all,
Apologies for the relatively long email, but I figure it's better to
give too much information than not enough. I've run into a bit of
difficulty backing up a large directory tree that has me not being
able to do a successful backup in over a month now. I'm attempting to
back up about 70GB
14 matches
Mail list logo
