Re: Q: Backing up Netware3 via ncpfs?
Olivier Nicole wrote: If I am not wrong, amanda needs to update some information on the files it had backed-up, in order to keep track of what file are changing or not since last back-up. Yes, but not in the files or inodes itself. That tracking info managed by amanda and is stored in the directory you specified when compiling amanda (--with-gnutar-listdir=...), probably ~/amanda/gnutar-lists. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Q: Backing up Netware3 via ncpfs?
On Thursday, 12.06.2003 at 11:59 +0100, Martin Hepworth wrote: how are you backing up the mount point? gnutar I guess, in which case are you using the latest version... Using tar, version 1.13.25 ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
On Thursday, 12.06.2003 at 12:12 -0400, Jon LaBadie wrote: Unix, in the inode allocated to each file, keeps three time stamps, collectively known as mactime stamps as they are data Modification, data Access, and inode Change times. Not all OS's keep these same 3 time stamps, yet to make nfs mounts work (I presume ncpmount is really doing an underlying nfs mount or something similar) the mactimes have to mimiced for use within a unix system. I can see a maping of ctime for example just tracking mtime, or maybe registering the date and time of the ncpmount command or ??? Anything that might throw tar off when it goes and looks has any change occured. Just a thought with no facts. OK, some stuff for me to check out - thanks Jon. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
On Friday, 13.06.2003 at 09:39 +0200, Paul Bijnens wrote: If I am not wrong, amanda needs to update some information on the files it had backed-up, in order to keep track of what file are changing or not since last back-up. Yes, but not in the files or inodes itself. That tracking info managed by amanda and is stored in the directory you specified when compiling amanda (--with-gnutar-listdir=...), probably ~/amanda/gnutar-lists. A stat of one of the files on the ncp filesystem looks like this: File: pm-net2.ini Size: 14025 Blocks: 28 IO Block: -4611692065741340160 Regular File Device: 15h/21d Inode: 1517Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: Wed Jun 11 00:00:00 2003 Modify: Wed Jun 4 12:08:00 2003 Change: Tue Jun 3 11:07:06 2003 This file, according to its timestamp was changed at 12:08 on June 4th. Does anything look odd, apart from that? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
Dave Ewart wrote: A stat of one of the files on the ncp filesystem looks like this: File: pm-net2.ini Size: 14025 Blocks: 28 IO Block: -4611692065741340160 Regular File Device: 15h/21d Inode: 1517Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: Wed Jun 11 00:00:00 2003 Modify: Wed Jun 4 12:08:00 2003 Change: Tue Jun 3 11:07:06 2003 This file, according to its timestamp was changed at 12:08 on June 4th. The mtime + the inode number are compared by gnutar. Maybe linux fakes inodes for ncpmounts and maybe they don't stay constant between mounts. Have a look at the files in gnutar-lists. They look like: 35651587 423837 ./lant/lib 35651587 891648 ./lant24/var/spool/data/in 35651587 341248 ./lant24/Nl-Fr 35651587 522880 ./lant24/En-SN/lib 35651587 181633 ./lant/En-Es The first number is the mtime (in seconds since epoch), the second number is the inode number, followed by the filename. You find files named: (in perl notation:) $host . _ . ($dir =~ s!/!_!g) . $level A e.g. host__0 for the level 0 backup of the root filesystem. A level 1 backup is compared to the status of the last level 0 backup. (or maybe you just have problems with accessing the gnutar-lists dir?) Does anything look odd, apart from that? Dave. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Q: Backing up Netware3 via ncpfs?
On Friday, 13.06.2003 at 12:49 +0200, Paul Bijnens wrote: A stat of one of the files on the ncp filesystem looks like this: File: pm-net2.ini Size: 14025 Blocks: 28 IO Block: -4611692065741340160 Regular File Device: 15h/21d Inode: 1517Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: Wed Jun 11 00:00:00 2003 Modify: Wed Jun 4 12:08:00 2003 Change: Tue Jun 3 11:07:06 2003 This file, according to its timestamp was changed at 12:08 on June 4th. The mtime + the inode number are compared by gnutar. Maybe linux fakes inodes for ncpmounts and maybe they don't stay constant between mounts. Have a look at the files in gnutar-lists. They look like: 35651587 423837 ./lant/lib 35651587 891648 ./lant24/var/spool/data/in 35651587 341248 ./lant24/Nl-Fr 35651587 522880 ./lant24/En-SN/lib 35651587 181633 ./lant/En-Es The first number is the mtime (in seconds since epoch), the second number is the inode number, followed by the filename. You find files named: (in perl notation:) $host . _ . ($dir =~ s!/!_!g) . $level A e.g. host__0 for the level 0 backup of the root filesystem. A level 1 backup is compared to the status of the last level 0 backup. Hmmm - the 'seconds since epoch' is clearly wrong for all the Netware gnutar lists (it is showing 0, rather than something corresponding approximately to 'this year'). Seems like the Netware mount is getting a rogue timestamp which is making AMANDA think everything is new. Your help has been useful - you may have directed me towards the real problem. Now all I need to do is figure out the right way to mount the Netware filesystems ... Thanks Paul, Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
Oops!!! Following up on myself again :-) Dave Ewart wrote: On Friday, 13.06.2003 at 12:49 +0200, Paul Bijnens wrote: A stat of one of the files on the ncp filesystem looks like this: File: pm-net2.ini Size: 14025 Blocks: 28 IO Block: -4611692065741340160 Regular File Device: 15h/21d Inode: 1517Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: Wed Jun 11 00:00:00 2003 Modify: Wed Jun 4 12:08:00 2003 Change: Tue Jun 3 11:07:06 2003 This file, according to its timestamp was changed at 12:08 on June 4th. The mtime + the inode number are compared by gnutar. Maybe linux fakes inodes for ncpmounts and maybe they don't stay constant between mounts. Have a look at the files in gnutar-lists. They look like: 35651587 423837 ./lant/lib 35651587 891648 ./lant24/var/spool/data/in 35651587 341248 ./lant24/Nl-Fr 35651587 522880 ./lant24/En-SN/lib 35651587 181633 ./lant/En-Es The first number is the mtime (in seconds since epoch), the second I was too fast. The first number on each line is the device number. The timestamp is the very first line (a number alone). The mtime of each file is compared to that single timestamp only. number is the inode number, followed by the filename. You find files named: (in perl notation:) $host . _ . ($dir =~ s!/!_!g) . $level A e.g. host__0 for the level 0 backup of the root filesystem. A level 1 backup is compared to the status of the last level 0 backup. Hmmm - the 'seconds since epoch' is clearly wrong for all the Netware gnutar lists (it is showing 0, rather than something corresponding There are some comments in the gnutar source about handling nfs special: the device name is ignored in this case, so that all nfs mounted files are assumed to be one big filesystem. Maybe ncpmounts get the same behaviour? (And get devicenumber 0 to indicate it is an nfs-or-alike device) approximately to 'this year'). Seems like the Netware mount is getting a rogue timestamp which is making AMANDA think everything is new. Your help has been useful - you may have directed me towards the real problem. Now all I need to do is figure out the right way to mount the Netware filesystems ... Thanks Paul, Not yet :-) Dave. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Q: Backing up Netware3 via ncpfs?
Jon LaBadie wrote: The mtime + the inode number are compared by gnutar. Paul, I haven't looked at the code, but wouldn't it use ctime rather than mtime? If a file has had its permissions or ownership changed that file should also be a candidate for backing up so that restoration is accurate. Yes you're right (but I'm too, a little): Having a closer look in the code File incremen.c 395if (0 getline (buf, bufsize, fp)) ... (read the first line from the file, error checking etc) 400unsigned long u = (errno = 0, strtoul (buf, ebuf, 10)); ... (convert to long int, and some more error checking) 409 newer_mtime_option = t; OK, now the newer_mtime_option is initialized from the integer on the first line in the file. Then: 299else 300 if (children == CHANGED_CHILDREN 301 stat_data.st_mtime newer_mtime_option 302 (!after_date_option 303 || stat_data.st_ctime newer_ctime_option)) 304add_to_accumulator (accumulator, N, 1); 305 else 306add_to_accumulator (accumulator, Y, 1); And indeed it is compared to mtime!!! I could not find the point where newer_ctime_option was initialised. BUT, a closer look after receiving your mail revealed: in common.h: #define newer_ctime_option newer_mtime_option So gnutar compares both ctime and mtime of each file to the same timestamp. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Q: Backing up Netware3 via ncpfs?
Dear all, Recently added a couple of netware servers to our Amanda backup regime - I used ncpmount to give the servers mount points and added the mount points to the disklist. The files backed up successfully on their first night, as a 'level 0' full backup; however, I notice today that the next night's 'level 1' backup actually appears to have backed up all files again, despite the fact that very few files will have changed. The servers are Netware 3 servers, and have been mounted read-only using: ncpmount -S server -U username -f 444 -d 555 /mount/point/blah I can't find anything helpful in the archives about backing up Netware servers in this way. Anyone got any hints? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
Dave Ewart wrote: Dear all, Recently added a couple of netware servers to our Amanda backup regime - I used ncpmount to give the servers mount points and added the mount points to the disklist. The files backed up successfully on their first night, as a 'level 0' full backup; however, I notice today that the next night's 'level 1' backup actually appears to have backed up all files again, despite the fact that very few files will have changed. The servers are Netware 3 servers, and have been mounted read-only using: ncpmount -S server -U username -f 444 -d 555 /mount/point/blah I can't find anything helpful in the archives about backing up Netware servers in this way. Anyone got any hints? Dave. Dave how are you backing up the mount point? gnutar I guess, in which case are you using the latest version... -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd +44 (0)1865 842300 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Re: Q: Backing up Netware3 via ncpfs?
On Thu, Jun 12, 2003 at 11:45:24AM +0100, Dave Ewart wrote: Dear all, Recently added a couple of netware servers to our Amanda backup regime - I used ncpmount to give the servers mount points and added the mount points to the disklist. The files backed up successfully on their first night, as a 'level 0' full backup; however, I notice today that the next night's 'level 1' backup actually appears to have backed up all files again, despite the fact that very few files will have changed. The servers are Netware 3 servers, and have been mounted read-only using: ncpmount -S server -U username -f 444 -d 555 /mount/point/blah I can't find anything helpful in the archives about backing up Netware servers in this way. Conceptual guesswork as I know nothing about Netware. Unix, in the inode allocated to each file, keeps three time stamps, collectively known as mactime stamps as they are data Modification, data Access, and inode Change times. Not all OS's keep these same 3 time stamps, yet to make nfs mounts work (I presume ncpmount is really doing an underlying nfs mount or something similar) the mactimes have to mimiced for use within a unix system. I can see a maping of ctime for example just tracking mtime, or maybe registering the date and time of the ncpmount command or ??? Anything that might throw tar off when it goes and looks has any change occured. Just a thought with no facts. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Q: Backing up Netware3 via ncpfs?
The servers are Netware 3 servers, and have been mounted read-only using: If I am not wrong, amanda needs to update some information on the files it had backed-up, in order to keep track of what file are changing or not since last back-up. I would think that if the file systems are readonly, those information cannot be reccorded and so amanda would not know on the next run that it had already been there. Olivier
