Re: amrecover not listing all files in backup.
--On Tuesday, January 11, 2005 21:55:45 -0700 Dwight Tovey <[EMAIL PROTECTED]> wrote: > > Frank Smith said: >> --On Tuesday, January 11, 2005 18:12:55 -0700 Dwight Tovey >> <[EMAIL PROTECTED]> wrote: >> > >> Are you sure your index files are good? Do the files look like: >> /somedir/file1 >> >> or is it more like: >> >> 8945983969/somedir/file1 >> >> >> If your index files contain the large random leading numbers, you are >> using a broken version of gnutar and amrecover won't work properly. >> I believe it must be greater than or equal to 1.13.19. although I >> recall problems with some of the 1.14 series as well. >> > > Aha. My Solaris system didn't have gnutar installed, so in the process of > installing the Amanda client I had downloaded the source from gnu.org (the > link on the Amanda installation notes pages wasn't responding at the > time). I assumed (bad idea) that this would be the latest working > version, but it turns out that it was 1.13. I've now downloaded the > 1.13.25 source through the Amanda link, so I'll install that and see what > I end up with. > > Is this problem with the index files the only problem? In other words, > can I fix the index files by passing them through sed to remove that > random number and then expect every thing else to be OK? My faded memories here don't recall it being that simple. All your data is on the tapes, but in some cases the directories themselves were saved as numbers. Best solution is to fix your tar and use amadmin to force a level 0 on the affected DLE's as soon as possible, and if you're lucky you won't ever need to recover from those old tapes before you make it through your tapecycle and overwrite them. As you found out, it is possible to get files from them, it's just more work. Perhaps someone on the list has been bitten more recently and can give you more details on the effects and workarounds. Frank > > Thanks for the response. > > /dwight > > -- > Dwight N. Tovey > email: [EMAIL PROTECTED] > web: http://www.dtovey.net/~dwight > --- > What I need is a list of specific unknown problems that we will encounter.
Re: amrecover not listing all files in backup.
Frank Smith said: > --On Tuesday, January 11, 2005 18:12:55 -0700 Dwight Tovey > <[EMAIL PROTECTED]> wrote: > > Are you sure your index files are good? Do the files look like: > /somedir/file1 > > or is it more like: > > 8945983969/somedir/file1 > > > If your index files contain the large random leading numbers, you are > using a broken version of gnutar and amrecover won't work properly. > I believe it must be greater than or equal to 1.13.19. although I > recall problems with some of the 1.14 series as well. > Aha. My Solaris system didn't have gnutar installed, so in the process of installing the Amanda client I had downloaded the source from gnu.org (the link on the Amanda installation notes pages wasn't responding at the time). I assumed (bad idea) that this would be the latest working version, but it turns out that it was 1.13. I've now downloaded the 1.13.25 source through the Amanda link, so I'll install that and see what I end up with. Is this problem with the index files the only problem? In other words, can I fix the index files by passing them through sed to remove that random number and then expect every thing else to be OK? Thanks for the response. /dwight -- Dwight N. Tovey email: [EMAIL PROTECTED] web: http://www.dtovey.net/~dwight --- What I need is a list of specific unknown problems that we will encounter.
Re: amrecover not listing all files in backup.
--On Tuesday, January 11, 2005 18:12:55 -0700 Dwight Tovey <[EMAIL PROTECTED]> wrote: > Hello all - > > I've recently started using Amanda for my backup strategy, and I'm having > a problem with amrecover. > > I set up my tape/index server on a RH 7.3 system with a 20G holding disk > and a 4mm DAT drive (DDS-2). Backing up the server itself seemed to be > working, so I next added a client system running Solaris 9. Again the > backups seem to be working, so next I wanted to try a file recover. On > the Solaris client I launched amrecover, set the disk, and started > browsing. This is where I ran into a problem: it looks like some of the > files are missing from the index. > > Back on the server, I took a look at the index file for that host/disk, > and everything looks fine (it includes entries for the files that I > noticed missing in amrecover). Next I used amrestore to extract the > GNUTAR file from the tape, and the files are in the tar file. So it looks > like the problem is only with amrecover. Note that I see the same results > if I run amrecover on either the client or the server. > > I guess this isn't really critical since I can get my missing files with > amrestore if I have to, but I would like to figure out what is going on > here. Any ideas? Are you sure your index files are good? Do the files look like: /somedir/file1 or is it more like: 8945983969/somedir/file1 If your index files contain the large random leading numbers, you are using a broken version of gnutar and amrecover won't work properly. I believe it must be greater than or equal to 1.13.19. although I recall problems with some of the 1.14 series as well. Frank > > Thanks > /dwight > > -- > Dwight N. Tovey > email: [EMAIL PROTECTED] > web: http://www.dtovey.net/~dwight > --- > Eagles may soar, but weasles don't get sucked into jet engines.
Re: amrestore problem, headers ok but no data
On Tuesday 11 January 2005 16:40, Jon LaBadie wrote: >On Tue, Jan 11, 2005 at 03:40:47PM -0500, Brian Cuttler wrote: >> Amanda user list, >> >> I've spoken to Harry at Condre systems and he confirmed what we >> where seeing. The jukebox robot is a narrow bus so that are two >> changes we need to make. >> >> 1) We want to move the jukebox/SDLT to be the last device on >>the daisy chain. >> >> 2) We want to terminate the jukebox-robot, so we need to make >>certain that the live port on the box hits the SDLT before >>we reach (electically) the robot. >> >> Hopefully this will have a positive effect on both SDLT drives. > >Not a scsi expert here, but if you terminate the jukebox, wouldn't >that terminate only the narrow portion of the bus leaving the extra >lines of the wide bus unterminated. Might there be some kind of >device/cable to go from wide -> narrow terminating the unused lines? > >Also, I think that if both types of devices exist on the same bus, >the lower performance one determines the performance of the entire >bus. That narrow jukebox may hurt your sdlt performance just by >being on the bus. Some of my scsi adapters have multiple channels >and buses. Perhaps you could run the sdlt's on one channel, wide, >and the jukebox on another, narrow or wide. I added a cheap second >controller from a dead system for a very similar purpose, external >devices that were narrow when the main controller was driving only >wide devices. Its two channels were used for different speed > devices. > >jl Generally speaking Jon, thats very good advice. In any event, where there is a transition to narrow devices, the unused lines must be properly terminated. To many folks forget that a a scsi bus is indeed an rf transmission line, subject to the usual rules about vswr. And double handicapped because the cable is, compared to a piece of well built coax, pretty much a guestimate as to its operating impedance, usually quoted as being in the 120 to 130 ohm territory, hence the commonly used resistive termination of a pair of resistors attached to the data line, a 220 ohm connected to the +5 volt line, and a 330 ohm connected to ground. It works quite well provided the resting voltage on the data lines can be held well above the 2.6 volt region, preferably at nearly 3.0 volts, giving an equal noise margin for both a logic zero and a logic one. Having that isolation diode in series with this feed often drops that voltage into the very low noise margin region below 2.6 volts. At that point you start sacrificing virgins etc to make it work. As to the whole chain being restricted to the speed of the slowest device, I've heard that, but it doesn't, on the face of it, make a lot of sense to me given that the drivers are properly written to auto-detect whats narrow and slow, and whats wide and fast. But thats a given I wouldn't swear about, at maybe... Driver quality does vary unfortunately depending on the authors whims and expertise at the time. If Brian has an old card he can stick in just to run the robot, it sure would be worth the try. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
amrecover not listing all files in backup.
Hello all - I've recently started using Amanda for my backup strategy, and I'm having a problem with amrecover. I set up my tape/index server on a RH 7.3 system with a 20G holding disk and a 4mm DAT drive (DDS-2). Backing up the server itself seemed to be working, so I next added a client system running Solaris 9. Again the backups seem to be working, so next I wanted to try a file recover. On the Solaris client I launched amrecover, set the disk, and started browsing. This is where I ran into a problem: it looks like some of the files are missing from the index. Back on the server, I took a look at the index file for that host/disk, and everything looks fine (it includes entries for the files that I noticed missing in amrecover). Next I used amrestore to extract the GNUTAR file from the tape, and the files are in the tar file. So it looks like the problem is only with amrecover. Note that I see the same results if I run amrecover on either the client or the server. I guess this isn't really critical since I can get my missing files with amrestore if I have to, but I would like to figure out what is going on here. Any ideas? Thanks /dwight -- Dwight N. Tovey email: [EMAIL PROTECTED] web: http://www.dtovey.net/~dwight --- Eagles may soar, but weasles don't get sucked into jet engines.
Re: amrestore problem, headers ok but no data
Jon, Recommended buying an additional scsi card more than once to the system's owners, haven't made the case yet (maybe now). I would really have liked the raid array on a separate bus from the tape drives. I have to trust that the proper cabeling to terminate the additional lines is present in the jukebox casing as the wiring is inaccessible and the sdlt completely enclosed (there is a door that slides open to admit to expel cartridges) and only well, 4 connection, 2 scsi (in and out), power and a port for a serial console. I agree with you completely but all I can hope for at the moment is to get the narrowest bus as far away from the cpu as I can. thanks, Brian On Tue, Jan 11, 2005 at 04:40:40PM -0500, Jon LaBadie wrote: > Not a scsi expert here, but if you terminate the jukebox, wouldn't > that terminate only the narrow portion of the bus leaving the extra > lines of the wide bus unterminated. Might there be some kind of > device/cable to go from wide -> narrow terminating the unused lines? > > Also, I think that if both types of devices exist on the same bus, > the lower performance one determines the performance of the entire > bus. That narrow jukebox may hurt your sdlt performance just by > being on the bus. Some of my scsi adapters have multiple channels > and buses. Perhaps you could run the sdlt's on one channel, wide, > and the jukebox on another, narrow or wide. I added a cheap second > controller from a dead system for a very similar purpose, external > devices that were narrow when the main controller was driving only > wide devices. Its two channels were used for different speed devices. > > jl > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Tue, Jan 11, 2005 at 03:40:47PM -0500, Brian Cuttler wrote: > > Amanda user list, > > I've spoken to Harry at Condre systems and he confirmed what we > where seeing. The jukebox robot is a narrow bus so that are two > changes we need to make. > > 1) We want to move the jukebox/SDLT to be the last device on >the daisy chain. > > 2) We want to terminate the jukebox-robot, so we need to make >certain that the live port on the box hits the SDLT before >we reach (electically) the robot. > > Hopefully this will have a positive effect on both SDLT drives. Not a scsi expert here, but if you terminate the jukebox, wouldn't that terminate only the narrow portion of the bus leaving the extra lines of the wide bus unterminated. Might there be some kind of device/cable to go from wide -> narrow terminating the unused lines? Also, I think that if both types of devices exist on the same bus, the lower performance one determines the performance of the entire bus. That narrow jukebox may hurt your sdlt performance just by being on the bus. Some of my scsi adapters have multiple channels and buses. Perhaps you could run the sdlt's on one channel, wide, and the jukebox on another, narrow or wide. I added a cheap second controller from a dead system for a very similar purpose, external devices that were narrow when the main controller was driving only wide devices. Its two channels were used for different speed devices. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrestore problem, headers ok but no data
Amanda user list, I've spoken to Harry at Condre systems and he confirmed what we where seeing. The jukebox robot is a narrow bus so that are two changes we need to make. 1) We want to move the jukebox/SDLT to be the last device on the daisy chain. 2) We want to terminate the jukebox-robot, so we need to make certain that the live port on the box hits the SDLT before we reach (electically) the robot. Hopefully this will have a positive effect on both SDLT drives. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amanda-client
Jason Davis wrote: Hello, I have installed amanda-client on a Debian box via apt. I have this entry in /etc/inetd.conf amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad however , when I restart inetd and run netstat -tap I do not see any amanda daemons listening. Anyone know what I am doing wrong? What ports should be listening on a amanda client box? Port: 10080/udp "netstat -t" only shows tcp entries. Omit the -t option. You want see any amanda daemons, when no amanda server asks them to run either. -- 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 * ***
amanda-client
Hello, I have installed amanda-client on a Debian box via apt. I have this entry in /etc/inetd.conf amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad however , when I restart inetd and run netstat -tap I do not see any amanda daemons listening. Anyone know what I am doing wrong? What ports should be listening on a amanda client box? Thanks, Jason Davis
Re: Antwort: Re: Incredible slow write / Converting tapes
On Tuesday 11 January 2005 09:16, Stefan G. Weichinger wrote: >Hi, > >on Dienstag, 11. Jänner 2005 at 15:12 I wrote to amanda-users: > >SGW> There has been a thread lately in which Gene Heskett described > how to SGW> do that. I paste the relevant part in here: > >Forgot to note that I think this procedure should go into the docs >somewhere. Needs some general re-writing before, maybe. Yeah, like putting stuff in the right chronological order, which I didn't in what you snipped. My bad. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: Antwort: Re: Incredible slow write / Converting tapes
On Tuesday 11 January 2005 09:12, Stefan G. Weichinger wrote: >Hi, Sandra, > >on Dienstag, 11. Jänner 2005 at 14:50 you wrote to amanda-users > >(in english, obwohl wir beide Deutsch schreiben könnten, aber dann >versteht hier keiner was ;-) ): > >SKsdd> Hi Stefan, > >SKsdd> errrm, stupid and confused as I was I actually changed >SKsdd> it to 32 bytes (!), but now I corrected it, setting a value > of SKsdd> 32768. > >SKsdd> Sorry for messing this up. I now started a new try with >SKsdd> this setting. My fault, that I didn´t made a written notice >SKsdd> when I changed the blocksize on the old machine. >SKsdd> Now I hope, it will run as good as it used to before I > changed the hardware. > >The kernel-messages might have resulted from this setting, let's > see. I assume that you now have documented this setting properly > ... > >SKsdd> Resulting from the several tries, I now have several >SKsdd> tapes labeled with various blocksizes. How can I convert them >SKsdd> back to the correct one. I assume amlabel won´t do it, cause >SKsdd> when I tried, it is not able to read the tape header. > >There has been a thread lately in which Gene Heskett described how > to > >do that. I paste the relevant part in here: >> You would be useing the setblk and defblksize, or the equ in your >> copy. From the cli: > >#>>mt -f device setblk 32768 >#>>mt -f device defblksize 32768 > >> Then you can use a > >#>>dd if=/path/to/device of=scratch count=1 > >> This will read the tapes label out to a tmp file you'll need later > >#>>mt -f device rewind > >> Then issue the above pair of commands > >#>>dd if=scratch of=path/to/device bs=32768 xx=xxx > >> Where the xx=xx stuff is replaced by whatever command >> dd uses to make it pad a short input file on out to the blocksize >> I'd have typed it here but I've forgotten it, check the manpage >> for that detail. >> >> Now feed the drive enough data to make it flush the buffers making >> it refresh the expected bloccksize in the hidden header, so figure >> out how many of those 32768 chunks will cause the drives >> advertized buffer to overflow, and use > >#>>dd of=/path/to/device if=dev/zero bs=32768 count #howmany > >The thread is named "amrestore problem, headers ok but no data" and > is rather huge right now ... > >SKsdd> Again sorry for my confusing posts, but I am working on >SKsdd> this quite a few days and the more I try the more confused I >SKsdd> get. > >We all know this sort of days ... no problem. Given that the tapes she has made aren't going to be terribly usefull anyway Stephan, my thoughts run toward doing an amrmtape on those, and then relabeling them again once the correct blocksize is set, bearing in mind that this *must* be reset everytime a different tape is loaded into the drive until all have been re-written with the new proper blocksize, and done before the labeling of each tape is done. Thinking over a 32 byte block, just the label would be 2 blocks! Yeah, relabel them as above. Just don't forget to reset the blocksize after each tape has been accepted by the drive, and before relabeling each tape. That should work. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: amrestore problem, headers ok but no data
On Tue, Jan 11, 2005 at 09:11:31AM +0100, Stefan G. Weichinger wrote: > The minimum blocksize value > is 32 KBytes. The maximum blocksize value is 32 > KBytes. The man pages have configure variables, which are expanded during "make". Presumably the maximum block size is one of these, while the minimum is simple, hard-coded text. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, "Foucault's Pendulum"
Re: Backup priorities and initialization of backup
Gil Naveh wrote: Hello, I am quit new with Amanda and I don’t understand an important concept regarding Amanda. I realize that Amanda decides what type of backup to perform (level 0 , level 1 etc) according to its algorithm. However, how does it knows which backup level to perform when a user have a tape drive with X different tapes that are manually changed? Is there a file that tells Amanda which backups has been performed and if so what is this file name? That info comes from different places. Look for a directory named ~amanda/TheConfig (for for each of your configs): all (most) files in there keep part of the information. Note that this is different from etc/TheConfig, which some people (like me) have put in ~amanda/etc/TheConfig, which contains the disklist and amanda.conf file for TheConfig. One of the important info sources, which is even human readable, is found in the "curinfo" directory. The normal way to look that at the info is through the utility program "amadmin". Like this: amadmin TheConfig info also nice are: amadmin TheConfig find amadmin TheConfig due amadmin TheConfig balance (balance is only meaningful after at least one complete dumpcycle) When using dump or variants, each client keeps the timestamps of the different levels in /etc/amandates. When using gnutar, you have to create a directory "gnutar-lists" on each client which contains info for the incremental levels of gnutar. Finally, so far I have been changing the file disklist in order to check different backup scenarios. The file tapelist was automatically updated: Because "tapelist" is also a program maintained file, which one should normally not edit, I've stored that one in ~amanda/TheConfig too, instead of ~amanda/etc/TheConfig. At this point, I want to run the backup – which means I have to initialize all my experiments so far – any ideas on how to do so? In my setup, I would (as user amanda): mv ~amanda/TheConfig ~amanda/TheConfig_testphase mkdir ~amanda/TheConfig Followed by, several times: amcheck TheConfig and solve every problem amanda flags me. (Because I've probably forgotten something in the above explanation.) Then force a full backup for every host in the disklist entry (to avoid touch /etc/amandates or gnutar-lists on each client), with the command: amadmin TheConfig force thishost thathost anotherhost Which files do I have to modify in addition to the disklist file. When doing all DLE's at once, be prepared that amanda will complain loud that one tape is not enough to do all full backups at once. She will skip some DLE's in the beginning. Maybe add entries a few at a time in disklist. Maybe run amdump a few times manually on one day. It is wise to keep a "Test" configuration, instead of doing tests with the production environment. For such a config, you may use a different set of tapes, or vtapes (backup to disk). -- 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: Backup priorities and initialization of backup
On Tue, Jan 11, 2005 at 11:11:06AM -0600, Gil Naveh wrote: > Hello, I am quit new with Amanda and I don't understand an important concept > regarding Amanda. > > I realize that Amanda decides what type of backup to perform (level 0 , > level 1 etc) according to its algorithm. > > However, how does it knows which backup level to perform when a user have a > tape drive with X different tapes that are manually changed? Is there a > file that tells Amanda which backups has been performed and if so what is > this file name? > > Finally, so far I have been changing the file disklist in order to check > different backup scenarios. The file tapelist was automatically updated: > > The new tapelist file looks like: > > 20041222 DailySet105 reuse > > 20041222 DailySet104 reuse etc. > > > > At this point, I want to run the backup - which means I have to initialize > all my experiments so far - any ideas on how to do so? > > Which files do I have to modify in addition to the disklist file. > Years ago I had a script to do just the thing I think you are asking, leave the configuration along but make amanda think it is the first ever amdump of everything. Here are the things I think I had to do in the automated script. Others may add or subtract with their input. - blow away the current dump info, index info, and logs In my case these were in subdirs named in amanda.conf. The default amanda.conf keeps the logs in the top level of the config directory. I always modify it to /logs. No sense cluttering up a perfectly good config directory. So for me this was just three rm -rf /* commands. You might have to do something different about your logs. Don't remove the curinfo, index, and ?log? directories themselves, just their contents. - In the tapelist file change all the dates to a zero. This indicates unused. If you want your tapes used in sequence, sort the list with with the first tape you want used at the bottom and the last tape at the top, - If you use a changer and your changer script mantains any state files, you may need to edit or remove them. My changer script, chg-mtx, did not so I did not have to do anything there. When you do this remember that amanda must do a level 0 dump of everything disklist entry it sees the first time. After doing this, every entry will be new. So everything will get a full backup which may not be desireable. I would comment out all the entries in your disklist, then go back and uncomment one or two entries from each client. Run amdump, maybe even during the day. Uncomment a few more disklist entries and let amdump run at its normal crontab time. Next day a few more etc. You get into a balanced situation much quicker this way without having a massively huge first amdump run. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Backup priorities and initialization of backup
Hello, I am quit new with Amanda and I don’t understand an important concept regarding Amanda. I realize that Amanda decides what type of backup to perform (level 0 , level 1 etc) according to its algorithm. However, how does it knows which backup level to perform when a user have a tape drive with X different tapes that are manually changed? Is there a file that tells Amanda which backups has been performed and if so what is this file name? Finally, so far I have been changing the file disklist in order to check different backup scenarios. The file tapelist was automatically updated: The new tapelist file looks like: 20041222 DailySet105 reuse 20041222 DailySet104 reuse etc… At this point, I want to run the backup – which means I have to initialize all my experiments so far – any ideas on how to do so? Which files do I have to modify in addition to the disklist file. Thanks, Gil
Re: spaces in share/directory names
Hi, Paul, on Dienstag, 11. Jänner 2005 at 16:02 you wrote to amanda-users: >> Is it possible? I heard that recent versions of Samba accept >> share/directory names with spaces. What about Amanda? >> If it must be hacked, could anybody point me where to start? PB> Two possibilities; both not very confortable... There is (at least) a third one that I use in my test-setup here. It is limited to Linux because it depends on the ability to mount CIFS-shares. You may do something like mount.cifs //WKS001/C$ /mnt/cifs/WKS001/C Create a link: ln -s "/mnt/cifs/WKS001/C/Program Files" /somewhere/winprogs after this you may use plain GNUTAR in your dumptype and may use something like this in your disklist /somewhere/winprogs nt-tar 1 even with multiple excludes and etc. This is not a recommended thing yet, also Paul is right with his note about Windows-Programs ... Just to let you know ... Sure it is much easier to just create a new share called "Programs". -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: spaces in share/directory names
Filip Rembiałkowski wrote: I've started using Amanda instead of prioprietary software to backup whole NT domain. I'd like to have disklist entries with spaces, like: smbhost"//WKS001/C$/Program Files/Filthy App"nocomp-user-smbtar Is it possible? I heard that recent versions of Samba accept share/directory names with spaces. What about Amanda? If it must be hacked, could anybody point me where to start? Two possibilities; both not very confortable... 1. Hack the amanda code. The problem here is that a lot of places in the amanda source asume "whitespace separated fields", and in those routines there is no provision to protect spaces (with quotes, with backslashes, etc.) Changing it should take into consideration that you should stay compatible with older clients (even in the protocol to exchange information between server and client, there is this problem). 2. Most people that stumbled on this problem, opted for the easier workaround: create a new share name without spaces. Actually, I implemented a third way (as far as possible), to mitigate the not optimal support for windows machines in amanda: migrate as much as possible from Windows servers to Samba servers. PS. Making a backup of the program files is usually not enough in MS Windows; you also need the relevant settings in the registry. And those settings could be dependent on e.g. the order in which you install programs! Very messy... I limit my backups on Windows machines to data-files only. PPS. I'm not an MS Windows specialist. -- 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 * ***
spaces in share/directory names
Hello, I've started using Amanda instead of prioprietary software to backup whole NT domain. I'd like to have disklist entries with spaces, like: smbhost"//WKS001/C$/Program Files/Filthy App"nocomp-user-smbtar Is it possible? I heard that recent versions of Samba accept share/directory names with spaces. What about Amanda? If it must be hacked, could anybody point me where to start? -- Filip Rembialkowski Kolmet Sp. z o.o. tel. (+48 22) 533 2007
Re: Antwort: Re: Incredible slow write / Converting tapes
Hi, on Dienstag, 11. Jänner 2005 at 15:12 I wrote to amanda-users: SGW> There has been a thread lately in which Gene Heskett described how to SGW> do that. I paste the relevant part in here: Forgot to note that I think this procedure should go into the docs somewhere. Needs some general re-writing before, maybe. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Antwort: Re: Incredible slow write / Converting tapes
Hi, Sandra, on Dienstag, 11. Jänner 2005 at 14:50 you wrote to amanda-users (in english, obwohl wir beide Deutsch schreiben könnten, aber dann versteht hier keiner was ;-) ): SKsdd> Hi Stefan, SKsdd> errrm, stupid and confused as I was I actually changed SKsdd> it to 32 bytes (!), but now I corrected it, setting a value of SKsdd> 32768. SKsdd> Sorry for messing this up. I now started a new try with SKsdd> this setting. My fault, that I didn´t made a written notice SKsdd> when I changed the blocksize on the old machine. SKsdd> Now I hope, it will run as good as it used to before I changed the hardware. The kernel-messages might have resulted from this setting, let's see. I assume that you now have documented this setting properly ... SKsdd> Resulting from the several tries, I now have several SKsdd> tapes labeled with various blocksizes. How can I convert them SKsdd> back to the correct one. I assume amlabel won´t do it, cause SKsdd> when I tried, it is not able to read the tape header. There has been a thread lately in which Gene Heskett described how to do that. I paste the relevant part in here: > You would be useing the setblk and defblksize, or the equ in your copy. > From the cli: #>>mt -f device setblk 32768 #>>mt -f device defblksize 32768 > > Then you can use a #>>dd if=/path/to/device of=scratch count=1 > This will read the tapes label out to a tmp file you'll need later #>>mt -f device rewind > Then issue the above pair of commands #>>dd if=scratch of=path/to/device bs=32768 xx=xxx > Where the xx=xx stuff is replaced by whatever command > dd uses to make it pad a short input file on out to the blocksize > I'd have typed it here but I've forgotten it, check the manpage > for that detail. > > Now feed the drive enough data to make it flush the buffers making > it refresh the expected bloccksize in the hidden header, so figure > out how many of those 32768 chunks will cause the drives > advertized buffer to overflow, and use #>>dd of=/path/to/device if=dev/zero bs=32768 count #howmany The thread is named "amrestore problem, headers ok but no data" and is rather huge right now ... SKsdd> Again sorry for my confusing posts, but I am working on SKsdd> this quite a few days and the more I try the more confused I SKsdd> get. We all know this sort of days ... no problem. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Antwort: Re: Incredible slow write / Converting tapes
Hi Stefan, errrm, stupid and confused as I was I actually changed it to 32 bytes (!), but now I corrected it, setting a value of 32768. Sorry for messing this up. I now started a new try with this setting. My fault, that I didn´t made a written notice when I changed the blocksize on the old machine. Now I hope, it will run as good as it used to before I changed the hardware. Resulting from the several tries, I now have several tapes labeled with various blocksizes. How can I convert them back to the correct one. I assume amlabel won´t do it, cause when I tried, it is not able to read the tape header. Again sorry for my confusing posts, but I am working on this quite a few days and the more I try the more confused I get. Kind regards Sandra Krumme "Stefan G. Weichinger" <[EMAIL PROTECTED]> Gesendet von: [EMAIL PROTECTED] 11.01.2005 14:27 Bitte antworten zu amanda-users@amanda.org An amanda-users@amanda.org Kopie Thema Re: Incredible slow write / Converting tapes Hi, Paul, on Dienstag, 11. Jänner 2005 at 14:14 you wrote to amanda-users: >> These problems I had resolved by using fresh tapes and by setting the >> default block size of the tape device to 32, which was the original >> setting. PB> blocksize of 32 bytes? Or do you mean 32 Kbytes? PB> If the blocksize if 32 bytes, then, yes, that is incredebly slow. Errrm, yes ... -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Incredible slow write / Converting tapes
Hi, Paul, on Dienstag, 11. Jänner 2005 at 14:14 you wrote to amanda-users: >> These problems I had resolved by using fresh tapes and by setting the >> default block size of the tape device to 32, which was the original >> setting. PB> blocksize of 32 bytes? Or do you mean 32 Kbytes? PB> If the blocksize if 32 bytes, then, yes, that is incredebly slow. Errrm, yes ... -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Antwort: Re: Incredible slow write / Converting tapes
Hi Paul, no, no. 32 Kbytes of course not 32 bytes. I am using a Compaq 40/80 DLT drive and as far as I can remember I had to do this setting to get the whole thing working. Kind regards Sandra Krumme Paul Bijnens <[EMAIL PROTECTED]> 11.01.2005 14:14 An [EMAIL PROTECTED] Kopie amanda-users@amanda.org Thema Re: Incredible slow write / Converting tapes [EMAIL PROTECTED] wrote: > > after moving my backup hard- and software to another machine, I > encountered several problems. One was due to faulty tapes, the other due > to the fact that I didn´t knew the blocksize I set the tape device on > the old machine. > These problems I had resolved by using fresh tapes and by setting the > default block size of the tape device to 32, which was the original > setting. blocksize of 32 bytes? Or do you mean 32 Kbytes? > > Now my backup is up an running again. But when I start amdump, the > filesystems are dumped quickly as usual, but when the taper starts > writing it takes extremly long. > Here is an example: > > 10.0.1.5:/ 1 55424k writing to tape (12:20:40) > > Now its 13:42 and it is still writing. > > Any idea whats wrong now ? If the blocksize if 32 bytes, then, yes, that is incredebly slow. Personally, I prefer the variable block tape device (by setting default blocksize to zero), and specify the blocksize I need using the programs (32Kbyte by default for amanda, or "dd bs=..." etc.) -- Paul Bijnens, Xplanation Tel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +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 * ***
Antwort: Re: Incredible slow write / Converting tapes
Hi, this is what /var/log/messages tells me: Jan 11 12:20:41 XX kernel: application bug: dumper(20882) has SIGCHLD set t o SIG_IGN but calls wait(). Jan 11 12:20:41 XX kernel: (see the NOTES section of 'man 2 wait'). Workaro und activated. Jan 11 12:22:16 XX kernel: application bug: dumper(20882) has SIGCHLD set t o SIG_IGN but calls wait(). Jan 11 12:22:16 XX kernel: (see the NOTES section of 'man 2 wait'). Workaro und activated. Jan 11 12:24:43 XX kernel: application bug: dumper(20882) has SIGCHLD set t o SIG_IGN but calls wait(). Jan 11 12:24:43 lx18016 kernel: (see the NOTES section of 'man 2 wait'). Workaro : This seems to be the problem, but I have no idea how to fix it. I´ m running amanda-2.4.4 on RH Enterprise Linux. Kind regards Sandra Krumme "Stefan G. Weichinger" <[EMAIL PROTECTED]> Gesendet von: [EMAIL PROTECTED] 11.01.2005 14:07 Bitte antworten zu amanda-users@amanda.org An amanda-users@amanda.org Kopie Thema Re: Incredible slow write / Converting tapes Hi, [EMAIL PROTECTED], on Dienstag, 11. Jänner 2005 at 13:41 you wrote to amanda-users: SKsdd> Now my backup is up an running again. But when I start SKsdd> amdump, the filesystems are dumped quickly as usual, but when SKsdd> the taper starts writing it takes extremly long. SKsdd> Here is an example: SKsdd> 10.0.1.5:/ 1 55424k writing to tape (12:20:40) SKsdd> Now its 13:42 and it is still writing. SCSI-errors? Assuming Linux as your OS, what does /var/log/messages tell you? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Incredible slow write / Converting tapes
[EMAIL PROTECTED] wrote: after moving my backup hard- and software to another machine, I encountered several problems. One was due to faulty tapes, the other due to the fact that I didn´t knew the blocksize I set the tape device on the old machine. These problems I had resolved by using fresh tapes and by setting the default block size of the tape device to 32, which was the original setting. blocksize of 32 bytes? Or do you mean 32 Kbytes? Now my backup is up an running again. But when I start amdump, the filesystems are dumped quickly as usual, but when the taper starts writing it takes extremly long. Here is an example: 10.0.1.5:/155424k writing to tape (12:20:40) Now its 13:42 and it is still writing. Any idea whats wrong now ? If the blocksize if 32 bytes, then, yes, that is incredebly slow. Personally, I prefer the variable block tape device (by setting default blocksize to zero), and specify the blocksize I need using the programs (32Kbyte by default for amanda, or "dd bs=..." etc.) -- 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: Incredible slow write / Converting tapes
Hi, [EMAIL PROTECTED], on Dienstag, 11. Jänner 2005 at 13:41 you wrote to amanda-users: SKsdd> Now my backup is up an running again. But when I start SKsdd> amdump, the filesystems are dumped quickly as usual, but when SKsdd> the taper starts writing it takes extremly long. SKsdd> Here is an example: SKsdd> 10.0.1.5:/ 1 55424k writing to tape (12:20:40) SKsdd> Now its 13:42 and it is still writing. SCSI-errors? Assuming Linux as your OS, what does /var/log/messages tell you? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Incredible slow write / Converting tapes
Hi all, after moving my backup hard- and software to another machine, I encountered several problems. One was due to faulty tapes, the other due to the fact that I didn´t knew the blocksize I set the tape device on the old machine. These problems I had resolved by using fresh tapes and by setting the default block size of the tape device to 32, which was the original setting. Now my backup is up an running again. But when I start amdump, the filesystems are dumped quickly as usual, but when the taper starts writing it takes extremly long. Here is an example: 10.0.1.5:/ 1 55424k writing to tape (12:20:40) Now its 13:42 and it is still writing. Any idea whats wrong now ? Best regards Sandra Krumme
Re: implausibly old time stamp 1969-12-31 17:00:00
On Mon, 10 Jan 2005, Eric Siegerman wrote:
> On Mon, Jan 10, 2005 at 02:47:43PM -0700, Jason Davis wrote:
> > tar: ./2005-01-07_17-00-57/ibdata01.ibz: implausibly old time stamp
> > 1969-12-31 17:00:00
>
> For some reason, tar thinks the file's timestamp is 0, or else
> the timestamp recorded in the tarball is in fact 0. (1969-12-31
> 17:00:00 is the UNIX epoch, converted to your local timezone.)
> I'm not sure why it's happening.
>
> Are you sure you're using GNU tar for both the backup and the
> restore? If the backup used gtar but the restore used your
> vendor's tar, there might be an incompatibility.
I've seen the same message when restoring on a different machine than the
backup was taken. Both backup and restore machine had GNU tar, but different
versions (restore machine is an Athlon XP running current Debian testing,
backup machine is an Alpha running a very old Debian version (the one before
woody (slink?), I think)). Didn't notice any other problems, but I didn't do a
full restore anyway, I just had to look at some files in /etc.
If anyone is interested in more details, I can look up the version of GNU tar
in the backups (old machine itself is stored in mottballs right now).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: amrestore problem, headers ok but no data
Hi, Jon, on Montag, 10. Jänner 2005 at 22:19 you wrote to amanda-users: JL> In recent versions, amanda can work with blocksizes other than 32k. JL> I forget if it is a configure option needed during the build or JL> a parameter that can be set in amanda.conf. I've never used it. The parameter blocksize goes into the tapetype-section in amanda.conf. "man amanda" says about that parameter: blocksize "int" Default: 32 kbytes. How much data will be written in each tape record. The minimum blocksize value is 32 KBytes. The maximum blocksize value is 32 KBytes. The maximum is set during configure with --with-maxtapeblocksize. Maybe this is just documented wrong, as the minimum is the same as the maximum, except when you set another maximum with the configure-option. But as I see from the other thread, Brian is on another path right now ... maybe he'll come back to blocksizes later. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
