Quantum M1500?
Hi, Anyone have any experience with a Quantum M1500 Library? This is what we are concidering for our new library. Anything I should know before I spend ? Any suggestions on how to configure Amanda for it? -- Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
What features should I look for in a new library?
It is time to get a new tape library. We are outgrowing our old one. (30 DLT IV tapes, 1 drive, 29 hosts & 521Gbytes to be backed up). I now wonder what features I should look for. Perhaps someone can comment? Multiple tape drives: Our old library had only one drive installed. I could have added a second one, but I could not see how amanda would use it to advantage. Can amanda use a second (or third...) drive? Is there any benefit? Barcodes: Can amanda find a tape faster if the library supports barcodes? The current method of reading the headers of each tape is slow enough to make me willing to drive to work to look at the written labels on the tapes. AIT's "memory" (or whatever it is): Can this kind of mechanism be used instead of barcodes to find the tape quicker? Other features (or bugs) of each technology: Are there any other things that are good/bad of each technology (DLT, SDLT, LTO, ...)? Are there any gotchas for particular implementations? Like known incompatabilities? We are willing to change technologies as we will be using the new library in addition to the old (we have a good way to split the dump "domains"), but we are a little partial to DLT. Is there a list of the technologies and libraries available for each? I looked at www.backupcentral.com as mentioned in the FAQ-O-Matic, but all I found was links to the manufacturers pages. -- Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
Re: Amdump takes forever
Joshua Baker-LePain wrote: > > On Wed, 11 Jul 2001 at 10:44am, Gary Algier wrote > > > I have tried to read the amdump log, but I can't decode it. Are there > > any tools to help me figure out where the time is being used? > > 'man amstatus' Just what I needed! I missed that one. I guess somebody added it while I was not looking ;-). It shows: --- Using /var/amanda/Weekly/amdump from Fri Jul 6 19:45:00 EDT 2001 abel:/ 0 282225k wait for dumping abel:/home2 0 584393k wait for dumping abel:/home3 0 508214k wait for dumping abel:/home4 0 563139k wait for dumping angelica:/ 09341k wait for dumping angelica:/export/home0 166745k wait for dumping angelica:/opt0 28550k wait for dumping angelica:/usr0 72708k wait for dumping angelica:/usr/openwin0 85132k wait for dumping angelica:/var0 65571k wait for dumping bond:/ 0 15136k wait for dumping bond:/export/home0 1025601k wait for dumping bond:/usr0 652433k wait for dumping bond:/var0 15278k wait for dumping bruckner:/ 02223k wait for dumping bruckner:/home 0 318820k wait for dumping bruckner:/home1 0 499938k wait for dumping bruckner:/home2 0 839959k wait for dumping bruckner:/usr0 242340k wait for dumping bruckner:/var0 680k wait for dumping burn:/ 0 15132k wait for dumping burn:/usr0 363997k wait for dumping burn:/var01242k wait for dumping camelot:/0 304102k wait for dumping camelot:/home0 2263810k wait for dumping chuckie:/0 32320k finished (22:17:36) chuckie:/export/homea0 936672k finished (21:00:45) chuckie:/opt 0 233792k finished (22:16:46) chuckie:/usr 0 553792k finished (22:08:42) chuckie:/var 0 796096k finished (21:27:14) chuckie:/var/mail0 646752k finished (21:48:25) delilah:/0 340621k wait for dumping delilah:/home0 671364k wait for dumping delilah:/home1 0 995859k wait for dumping delilah:/home2 0 1445041k wait for dumping delilah:/home3 0 1745416k wait for dumping delilah:/home4 0 1271751k wait for dumping delilah:/home5 0 1043010k wait for dumping delilah:/home6 0 102k wait for dumping delilah:/home7 0 1227327k wait for dumping delilah:/home8 0 1481872k wait for dumping delilah:/home9 0 32k finished (20:25:37) delilah:/homea 0 3445192k wait for dumping delilah:/homeb 0 2637984k wait for dumping delilah:/homec 0 3688052k wait for dumping delilah:/homed 0 2737345k wait for dumping delilah:/homee 0 2585379k wait for dumping delilah:/opt 0 214049k wait for dumping dil:/0 10671k wait for dumping dil:/export 0 10463k wait for dumping dil:/export/homea0 183504k wait for dumping dil:/export/homeb0 519287k wait for dumping dil:/export/homec0 53k wait for dumping dil:/export/homed0 2620430k wait for dumping dil:/opt 0 254696k wait for dumping dil:/usr 0 484784k wait for dumping dil:/usr/news04694k wait for dumping dil:/usr/news/db 03558k wait for dumping dil:/var 0 60297k wait for dumping freeport:/ 08202k wait for dumping freeport:/export/home0 89100k wait for dumping freeport:/export/homea 0 1720854k wait for dumping freeport:/opt0 215813k wait for dumping freeport:/usr0 451879k wait for dumping freeport:/var
Amdump takes forever
My amdump is suddenly running for days. I have a special configuration named "Weekly" that does a level 0 dump of all file systems (with no record) that I have been running every Friday night. This always took until some time on Sunday, but lately it has carried over to Wednesday or even Thursday. Yes, I have added more file systems to dump, but how do I figure out why adding 5% to the work to be done makes it run for 100% longer? I have tried to read the amdump log, but I can't decode it. Are there any tools to help me figure out where the time is being used? Also, how do I "tune" this thing? Should I allow more parallel dumps? Or is that self defeating? I have been a happy user for several years, but I am now getting heat from my users who can't get files restored because the system is too busy doing backups. I can supply configs and logs upon request, but a little info may be helpful: Server: Amanda 2.4.2 on Solaris 8 with 52Gbyte holding disk Tapes: DLT7000 on an Exabyte 230D usually uses 5 tapes / run Clients: 182 file system on 25 hosts with amanda 2.4.1p1 or 2.4.2 with Solaris, Unixware, Sinix, HPUX, AIX, FreeBSD Can someone please help me make this run faster? -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 A self-addressed envelope would be addressed "envelope."
Re: How do I change the ctime of a vfat file?
I hope you realize that VFAT file systems don't have a ctime. Under Unix, ctime is defined as the last change to inode time. It gets set when ever one does a chown(), chmod(), link(), touch, etc. Here are the times associated with a file: Unix: mtime Last date/time modified ctime Last date/time of inode change atime Last date/time accessed DOS/Win* (gleaned by reading FreeBSD OS sources): MDate Last date modified MTime Last time of day modified CDate Creation date CTime Creation time of day ADate Last date accessed [Note: I can't find any ATime in the code] So, the real question is, what does the OS do when someone does a touch (obvious chown, link, etc, won't work)? Since the DOS/Win* idea of ctime is the creation time, I don't think it should change. Therefore, there should be no way to change the ctime. If one does make CDate/CTime writable, what does DOS/Win* do when the creation time is newer than the access or modify time? This should never happen, but if Unix can set it, ? Chris Karakas wrote: > > Martin Brown wrote: > > > How do I change the ctime of a vfat file? > > try moving it > > Sorry, I've tried it, but this does not change the *ctime* of a vfat > file. Check with ls -lc to see yourself. Any other ideas? > > -- > Regards > > Chris Karakas > Don´t waste your cpu time - crack rc5: http://www.distributed.net -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 This space intentionally left blank by the censors.
Re: Sun's L20 hardware.
"John R. Jackson" wrote: > > >Does anyone know if Amanda will work on a L20? ... > [snip] > > New with 2.4.2 is a much improved direct SCSI changer that issues the > commands itself. According to the web page, the L20 is SCSI based, > as most changers are these days, so I would bet it would either work > right away or with minimal changes, of which there are people on the > list who can help you get those done. > I would say that you shouldn't buy the L20 if you have not tried this. If you already have the L20, give it a try. I found that not all changers seem to work the same. I am trying right now to modify the chg-scsi code to handle an Exabyte 230D. Some changers need special functions written to decode results of some SCSI commands and the 230D seems to be one of these. On a side note: If anyone has experience with a 230D or is knowledgable about how chg-scsi works, I would apreciate hearing from you. I will (obviously) contribute back any changes. -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 This space intentionally left blank by the censors.
Where/how should bugs be reported?
I reported some bugs via sourceforge. That was a mistake. I tried again via email to this mailing list. These were replied to with an address of [EMAIL PROTECTED] So, where should bugs be reported? Any special format? Anything special I should do with context diffs if I have the fix? -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 This space intentionally left blank by the censors.
