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.
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
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 want a
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 parent
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
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 now. I'm
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
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 show all the
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 setting -
my original impression
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
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'm attempting to
back
11 matches
Mail list logo
