On Fri, 2005-12-02 at 22:52, Craig Barratt wrote:
> That's right. Getting rsync hardlinks tested and released is
> more important. Plus, with Roy's development of a BackupPC
> client (which will handle ACLs and a bunch of other things),
> tar is lower priority.
Hmmm, I wonder if there is any ch
[EMAIL PROTECTED] writes:
> Hm. Well I thought I found the problem (I couldn't ssh to [EMAIL PROTECTED]
> without getting a password prompt) but after I fixed that the problem
> still remained. Ratz!
>
> Here's the restorecmd:
>
> $Conf{TarClientRestoreCmd} = '$sshPath -q -x -l root $host /usr/b
Les Mikesell writes:
> On Fri, 2005-12-02 at 20:41, Craig Barratt wrote:
>
> > The next version of BackupPC and File::RsyncP will support
> > hardlinks. But there isn't a firm release date yet.
>
> If you want to work at it, it is possible to get incrementals
> right with gnutar. However it re
Hm. Well I thought I found the problem (I couldn't ssh to [EMAIL PROTECTED]
without getting a password prompt) but after I fixed that the problem
still remained. Ratz!
Here's the restorecmd:
$Conf{TarClientRestoreCmd} = '$sshPath -q -x -l root $host /usr/bin/env
LC_ALL=C $tarPath -x -p --numeric
On Fri, 2005-12-02 at 20:41, Craig Barratt wrote:
> The next version of BackupPC and File::RsyncP will support
> hardlinks. But there isn't a firm release date yet.
If you want to work at it, it is possible to get incrementals
right with gnutar. However it requires keeping track of
a file name
[EMAIL PROTECTED] writes:
> OK got a new error for you. Today I wanted to restore something for the
> first time.. and wouldn't you know it. Errors.. no restore happening.
>
> What I tried to do:
>
> I back up localhost to localhost (another drive, same machine).
> Now as a test I wanted to rest
Hey all,
OK got a new error for you. Today I wanted to restore something for the
first time.. and wouldn't you know it. Errors.. no restore happening.
What I tried to do:
I back up localhost to localhost (another drive, same machine).
Now as a test I wanted to restore /var/log/uucp.log. A 0byte
Craig Barratt writes:
> Yes, your explanation is correct. Tar and Smb incrementals are based
> only on mtime, so adding/deleting/renaming files, changing other
> meta-data, or unpacking an archive with old mtimes won't be
> detected.
I didn't mean to include file creation in this list.
Normally
Paul Fox writes:
> i just did a restore of a directory (happily not because of
> disaster, but because it was an easy way to get at some files
> that live on a machine that's currently offline) and had a big
> surprise.
>
> i was accessing an incremental backup tree. since all backups
> are "fil
Les Mikesell writes:
> On Fri, 2005-12-02 at 10:16, Andy wrote:
>
> > I see that the UIDs and GIDs recorded in the XFER log match those from
> > the directory listing. Great.
> >
> > I have downloaded and restored the tar archive from the most recent
> > backup, this time using the -p option t
i just did a restore of a directory (happily not because of
disaster, but because it was an easy way to get at some files
that live on a machine that's currently offline) and had a big
surprise.
i was accessing an incremental backup tree. since all backups
are "filled", i was very surprised when
On Fri, 2005-12-02 at 10:16, Andy wrote:
> I see that the UIDs and GIDs recorded in the XFER log match those from
> the directory listing. Great.
>
> I have downloaded and restored the tar archive from the most recent
> backup, this time using the -p option to preserve permissions:
>
>~# t
Andy wrote:
The UIDs and GIDs from the restored directory appear to be out of sync
with those of the original directory.
Have I done something wrong, or should I be concerned that there is a
problem with the meta-data stored in BackupPC?
I am the OP. Having just run a full backup and done
Hello List,
I use BackupPC 2.1.1 from Debian Sarge to backup a server. I use RSync
version 2.6.4 protocol version 29 also from Debian Sarge.
On the server that is being backed up the permissions of
/var/spool/postfix look like this:
~# ls /var/spool/postfix -la
drwx-- 18 postfix root
14 matches
Mail list logo
