Re: [BackupPC-users] incremental revelation
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 chance of getting the backuppc client's features rolled into rsync itself. ACLs/open file handling would be just as important there and a client that can't compare to the previous run is always going to have trouble getting old files under renamed directories in incrementals - or back-dated files on filesystems that don't keep separate ctimes. -- Les Mikesell [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backuppc restore failed.. huh?
[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/bin/env
> LC_ALL=C $tarPath -x -p --numeric-owner --same-owner -v -f - -C $shareName+';
>
> Now I've been going through some of the variables.. sshpath is set in
> localhost.pl:
>
> $Conf{SshPath} = '/usr/bin/ssh -p 1234';
> (yes we run sshd on another port)
>
> $tarPath is just /bin/tar as usual.. $host is localhost..
>
> Don't see the error yet..
$Conf{SshPath} needs to be just the executable. What I suspect
is happening is that BackupPC trying to run the program
"/usr/bin/ssh -p 1234", not /usr/bin/ssh, since it breaks up the
command into arguments before substituting variables. Try moving
the -p 1234 from $Conf{SshPath} to $Conf{TarClientRestoreCmd}.
By the way, if you restarted BackupPC it should complain that
$Conf{SshPath} is not a valid executable and refuse to start.
Craig
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] incremental revelation
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 requires keeping track of > a file name to use with the --listed-incremental option > and having write access somewhere on the client. Since > rsync works anyway I'm not sure it's worth the effort. 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. Craig --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backuppc restore failed.. huh?
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-owner --same-owner -v -f - -C $shareName+';
Now I've been going through some of the variables.. sshpath is set in
localhost.pl:
$Conf{SshPath} = '/usr/bin/ssh -p 1234';
(yes we run sshd on another port)
$tarPath is just /bin/tar as usual.. $host is localhost..
Don't see the error yet..
> > 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 file.
> >
> > I tell it to restore directly to the machine localhost.
> >
> > Result in the log file:
> >
> > 2005-12-03 04:20:49 Running: /usr/share/backuppc/bin/BackupPC_tarCreate -h
> > localhost -n 21 -s /var -t -r /log -p /log/ /log/uucp.log
> > 2005-12-03 04:20:54 Restore failed (BackupPC_tarCreate failed)
> >
> > Not a really informative log message..
> >
> > I tried the same command as user backuppc:
> >
> > [EMAIL PROTECTED]:~$ /usr/share/backuppc/bin/BackupPC_tarCreate -h
> > localhost -n
> > 21 -s /var -t -r /log -p /log/ /log/uucp.log
> ./log/uucp.log644010131560714012135 0ustar
> > rootrootDone: 1 files, 0 bytes, 0 dirs, 0 specials, 0 errors
> > [EMAIL PROTECTED]:~$
> >
> > Well, no errors, but no files created either.
>
> Yes, an archive with one file is created - you can see some of the
> archive contents in ascii, but pipe it into od -x so see it all.
>
> > Any thoughts? My localhost.pl contains:
> >
> > $Conf{XferMethod} = 'tar';
> > $Conf{TarShareName} = ['/etc'];
> > $Conf{TarShareName} = ['/boot', '/var', '/usr/local', '/etc'];
> > $Conf{TarClientCmd} = '/usr/bin/sudo /etc/backuppc/tarcreate -v -f - -C
> > $shareName+ --totals';
>
> I would guess $Conf{TarClientRestoreCmd} is wrong. What is
> it set to?
>
> Craig
>
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] incremental revelation
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 to use with the --listed-incremental option and having write access somewhere on the client. Since rsync works anyway I'm not sure it's worth the effort. -- Les Mikesell [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backuppc restore failed.. huh?
[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 restore /var/log/uucp.log. A 0byte file.
>
> I tell it to restore directly to the machine localhost.
>
> Result in the log file:
>
> 2005-12-03 04:20:49 Running: /usr/share/backuppc/bin/BackupPC_tarCreate -h
> localhost -n 21 -s /var -t -r /log -p /log/ /log/uucp.log
> 2005-12-03 04:20:54 Restore failed (BackupPC_tarCreate failed)
>
> Not a really informative log message..
>
> I tried the same command as user backuppc:
>
> [EMAIL PROTECTED]:~$ /usr/share/backuppc/bin/BackupPC_tarCreate -h
> localhost -n
> 21 -s /var -t -r /log -p /log/ /log/uucp.log
./log/uucp.log644010131560714012135 0ustar
> rootrootDone: 1 files, 0 bytes, 0 dirs, 0 specials, 0 errors
> [EMAIL PROTECTED]:~$
>
> Well, no errors, but no files created either.
Yes, an archive with one file is created - you can see some of the
archive contents in ascii, but pipe it into od -x so see it all.
> Any thoughts? My localhost.pl contains:
>
> $Conf{XferMethod} = 'tar';
> $Conf{TarShareName} = ['/etc'];
> $Conf{TarShareName} = ['/boot', '/var', '/usr/local', '/etc'];
> $Conf{TarClientCmd} = '/usr/bin/sudo /etc/backuppc/tarcreate -v -f - -C
> $shareName+ --totals';
I would guess $Conf{TarClientRestoreCmd} is wrong. What is
it set to?
Craig
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
[BackupPC-users] Backuppc restore failed.. huh?
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 file.
I tell it to restore directly to the machine localhost.
Result in the log file:
2005-12-03 04:20:49 Running: /usr/share/backuppc/bin/BackupPC_tarCreate -h
localhost -n 21 -s /var -t -r /log -p /log/ /log/uucp.log
2005-12-03 04:20:54 Restore failed (BackupPC_tarCreate failed)
Not a really informative log message..
I tried the same command as user backuppc:
[EMAIL PROTECTED]:~$ /usr/share/backuppc/bin/BackupPC_tarCreate -h
localhost -n
21 -s /var -t -r /log -p /log/ /log/uucp.log
./log/uucp.log644010131560714012135 0ustar
rootrootDone: 1 files, 0 bytes, 0 dirs, 0 specials, 0 errors
[EMAIL PROTECTED]:~$
Well, no errors, but no files created either.
Any thoughts? My localhost.pl contains:
$Conf{XferMethod} = 'tar';
$Conf{TarShareName} = ['/etc'];
$Conf{TarShareName} = ['/boot', '/var', '/usr/local', '/etc'];
$Conf{TarClientCmd} = '/usr/bin/sudo /etc/backuppc/tarcreate -v -f - -C
$shareName+ --totals';
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] incremental revelation
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 a new file is created with a current mtime, so it will be detected and backed up during an incremental. However, cp -p, unzip, tar -x are ways of creating new files that have old mtimes, so they will be missed in a tar or smbclient incremental. Craig --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] incremental revelation
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 "filled", i was very surprised when my restored tree was > obviously incomplete. then i remembered that i had created the > directory several days ago (but _after_ the most recent full > backup) by doing a "cp -a" of a neighboring directory (i was > cloning a build tree). of course the date-preserving nature > of "cp -a" meant that my tar-based incremental backup didn't pick > up any files whose dates were older than the previous full, even > though those files had never been backed up. 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. See the last link of: http://backuppc.sourceforge.net/faq/limitations.html > no data was actually lost, and all is well, but now i'm curious -- > would rsync have done the "right thing" in this case? Yes. Rsync incrementals check all the meta data, plus detecting new or deleted files. > the only reason i don't use rsync is because it doesn't preserve > hard links, which i use fairly frequently. but i may reconsider... The next version of BackupPC and File::RsyncP will support hardlinks. But there isn't a firm release date yet. Craig --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] UID/GID of restored files out of sync with those on server
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 to preserve permissions: > > > >~# tar xpvf restore.tar > > > > Yet when I list the restored directory I still see differing UIDs and GIDs: > > Tar will try to match the user name to the current password/nis/ldap > lookup during a restore unless you use the --numeric-owner option. > Perhaps you have a duplicate passwd entry for postgres and it is > finding the wrong one when restoring. That's right. The tar archive includes the uid/gid, but also includes the uname and gname. When BackupPC_tarCreate runs, it uses the correct uid/gid, but it adds the uname and gname based on the local (BackupPC server) machine, since it doesn't know the correct uname and gname from the client (that's not sent). So it is likely that the uid/gid are different on the BackupPC server and client. All that should be solved by using --numeric-owner on the tar extract, and similarly --numeric-ids on the rsync restore (that's the default in config.pl). Craig --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
[BackupPC-users] incremental revelation
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 my restored tree was obviously incomplete. then i remembered that i had created the directory several days ago (but _after_ the most recent full backup) by doing a "cp -a" of a neighboring directory (i was cloning a build tree). of course the date-preserving nature of "cp -a" meant that my tar-based incremental backup didn't pick up any files whose dates were older than the previous full, even though those files had never been backed up. no data was actually lost, and all is well, but now i'm curious -- would rsync have done the "right thing" in this case? the only reason i don't use rsync is because it doesn't preserve hard links, which i use fairly frequently. but i may reconsider... paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 35.4 degrees) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] UID/GID of restored files out of sync with those on server
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: > >~# tar xpvf restore.tar > > Yet when I list the restored directory I still see differing UIDs and GIDs: Tar will try to match the user name to the current password/nis/ldap lookup during a restore unless you use the --numeric-owner option. Perhaps you have a duplicate passwd entry for postgres and it is finding the wrong one when restoring. -- Les Mikesell [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] UID/GID of restored files out of sync with those on server
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 some further analysis I am replying to my own message with additional information. Below I include a sample from the XFER log for the most recent backup: create d 700 103/04096 var/spool/postfix/active create d 700 103/04096 var/spool/postfix/corrupt create d 700 103/04096 var/spool/postfix/defer create d 700 103/04096 var/spool/postfix/deferred create d 755 0/04096 var/spool/postfix/etc create d 700 103/04096 var/spool/postfix/flush create d 700 103/04096 var/spool/postfix/hold create d 700 103/04096 var/spool/postfix/incoming create d 755 0/04096 var/spool/postfix/lib create d1730 103/1064096 var/spool/postfix/maildrop create d 755 103/04096 var/spool/postfix/pid create d 700 103/04096 var/spool/postfix/private create d2710 103/1064096 var/spool/postfix/public create d 700 103/04096 var/spool/postfix/saved create d 700 103/04096 var/spool/postfix/trace create d 755 0/04096 var/spool/postfix/usr And a directory listing, this time using ls -lan to show numeric UIDs and GIDs: ~# ls /var/spool/postfix -lan drwx-- 18 103 0 4096 Apr 18 2005 active drwx-- 18 103 0 4096 Jul 25 04:00 bounce drwx-- 2 103 0 4096 Apr 15 2005 corrupt drwx-- 18 103 0 4096 Jun 14 17:14 defer drwx-- 18 103 0 4096 Jun 14 17:14 deferred drwxr-xr-x 2 0 0 4096 Oct 31 17:16 etc drwx-- 9 103 0 4096 Oct 25 15:51 flush drwx-- 2 103 0 4096 Apr 15 2005 hold drwx-- 18 103 0 4096 Dec 2 15:53 incoming drwxr-xr-x 2 0 0 4096 Oct 31 17:16 lib drwx-wx--T 2 103 106 4096 Dec 2 06:36 maildrop drwxr-xr-x 2 103 0 4096 Oct 31 17:17 pid drwx-- 2 103 0 4096 Oct 31 17:16 private drwx--s--- 2 103 106 4096 Oct 31 17:16 public drwx-- 2 103 0 4096 Apr 15 2005 saved drwx-- 2 103 0 4096 Apr 15 2005 trace drwxr-xr-x 3 0 0 4096 Apr 15 2005 usr 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: ~# tar xpvf restore.tar Yet when I list the restored directory I still see differing UIDs and GIDs: ~# ls /root/postfix -lan drwx-- 18 105 0 4096 Dec 2 16:01 active drwx-- 18 105 0 4096 Dec 2 16:01 bounce drwx-- 2 105 0 4096 Apr 15 2005 corrupt drwx-- 18 105 0 4096 Dec 2 16:01 defer drwx-- 18 105 0 4096 Dec 2 16:01 deferred drwxr-xr-x 2 0 0 4096 Dec 2 16:01 etc drwx-- 9 105 0 4096 Dec 2 16:01 flush drwx-- 2 105 0 4096 Apr 15 2005 hold drwx-- 18 105 0 4096 Dec 2 16:01 incoming drwxr-xr-x 2 0 0 4096 Dec 2 16:01 lib drwx-wx--T 2 105 107 4096 Dec 2 06:36 maildrop drwxr-xr-x 2 105 0 4096 Dec 2 16:01 pid drwx-- 2 105 0 4096 Oct 31 17:16 private -rw--- 1 0 0 1024 Dec 2 13:54 prng_exch drwx--s--- 2 105 107 4096 Dec 2 16:01 public drwx-- 2 105 0 4096 Apr 15 2005 saved drwx-- 2 105 0 4096 Apr 15 2005 trace drwxr-xr-x 3 0 0 4096 Dec 2 16:01 usr I dont understand why. If this is the result of my own stupidity then please feel free to point it out. Otherwise, does anyone have any suggestions? Thanks, Andy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
[BackupPC-users] UID/GID of restored files out of sync with those on server
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 4096 Apr 18 2005 active drwx-- 18 postfix root 4096 Jul 25 04:00 bounce drwx-- 2 postfix root 4096 Apr 15 2005 corrupt drwx-- 18 postfix root 4096 Jun 14 17:14 defer drwx-- 18 postfix root 4096 Jun 14 17:14 deferred drwxr-xr-x 2 rootroot 4096 Oct 31 17:16 etc drwx-- 9 postfix root 4096 Oct 25 15:51 flush drwx-- 2 postfix root 4096 Apr 15 2005 hold drwx-- 18 postfix root 4096 Dec 2 11:59 incoming drwxr-xr-x 2 rootroot 4096 Oct 31 17:16 lib drwx-wx--T 2 postfix postdrop 4096 Dec 2 06:36 maildrop drwxr-xr-x 2 postfix root 4096 Oct 31 17:17 pid drwx-- 2 postfix root 4096 Oct 31 17:16 private -rw--- 1 rootroot 1024 Dec 2 12:01 prng_exch drwx--s--- 2 postfix postdrop 4096 Oct 31 17:16 public drwx-- 2 postfix root 4096 Apr 15 2005 saved drwx-- 2 postfix root 4096 Apr 15 2005 trace drwxr-xr-x 3 rootroot 4096 Apr 15 2005 usr I have downloaded a tar archive of this directory and restored it to /root ON THE SAME BOX, and the file ownership looks like this this: ~# tar xvf restore.tar ~# ls /root/postfix -la drwx-- 18 amavis root 4096 Dec 2 11:57 active drwx-- 18 amavis root 4096 Dec 2 11:57 bounce drwx-- 2 amavis root 4096 Apr 15 2005 corrupt drwx-- 18 amavis root 4096 Dec 2 11:57 defer drwx-- 18 amavis root 4096 Dec 2 11:57 deferred drwxr-xr-x 2 root root 4096 Dec 2 11:57 etc drwx-- 9 amavis root 4096 Dec 2 11:57 flush drwx-- 2 amavis root 4096 Apr 15 2005 hold drwx-- 18 amavis root 4096 Dec 2 11:57 incoming drwxr-xr-x 2 root root 4096 Dec 2 11:57 lib drwx-wx--T 2 amavis clamav 4096 Dec 1 06:37 maildrop drwxr-xr-x 2 amavis root 4096 Dec 2 11:57 pid drwx-- 2 amavis root 4096 Oct 31 17:16 private -rw--- 1 root root 1024 Dec 1 19:57 prng_exch drwx--s--- 2 amavis clamav 4096 Dec 2 11:57 public drwx-- 2 amavis root 4096 Apr 15 2005 saved drwx-- 2 amavis root 4096 Apr 15 2005 trace drwxr-xr-x 3 root root 4096 Dec 2 11:57 usr 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? Does anyone have any suggestions how I might go about debugging this? Can I manually analyse the meta-data stored within BackupPC for this directory? Many Thanks, Andy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
