amcheck - why run it?
Lately, with the advent of some network viruses, I've had backups not occur when I run amcheck before running amdump. My script, which is run from crontab, checks to see if amcheck ran successfully before I allow amdump to run. I'm using samba to back up Windows servers across the network to my Sun server. Is there any good reason to have this type of procedure in place where amcheck must be successful before running amdump? Also, I don't run amverify either because I lack the time during the backup window for this. I'm not sure this is necessary either. What is amverify really checking? I don't think it checks what was dumped on tape vs what is on the disk. Is it necessary to make sure you really have a valid backup? Bob... -- Robert Zahn UNIX Systems Administrator Oklahoma City Community College S. May Avenue Oklahoma City, Ok 73159 [EMAIL PROTECTED][EMAIL PROTECTED] --
RE: amcheck - why run it?
> Lately, with the advent of some network viruses, I've had > backups not occur > when I run amcheck before running amdump. My script, which is run from > crontab, checks to see if amcheck ran successfully before I > allow amdump to > run. I'm using samba to back up Windows servers across the > network to my > Sun server. Is there any good reason to have this type of > procedure in > place where amcheck must be successful before running amdump? Instead of making amdump run in lockstep to amcheck, you might want to just have amcheck send you an e-mail if there is a problem. (See the -m option.) Then amdump will at least try to run even if amcheck failed. > > Also, I don't run amverify either because I lack the time > during the backup > window for this. I'm not sure this is necessary either. What > is amverify > really checking? I don't think it checks what was dumped on > tape vs what is > on the disk. Is it necessary to make sure you really have a > valid backup? I never really worried about amverify, because it only makes sure your backup ran. Instead, I would recommend doing a test restore at least once a month, which makes sure the backup worked, like amverify AND it makes sure that you can restore. (In our case, I was backing up SQL Server databases, and made sure that I could restore the database dump all the way from tape->amanda->samba->SQL Server.)
Re: amcheck - why run it?
Bob, I don't run amdump dependent on amcheck output - amdump can fail quite well on its own. Rather I run amcheck during business hours to verify that I have a proper tape in the drive. Just today we put WWWxx in the WWWVOLxx drive but where able to find and recify the problem during business today rather than having to fix/flush tomorrow. [Yes, I realize those two systems have idioticly similar names, bit of an historical accident...] > Lately, with the advent of some network viruses, I've had backups not occur > when I run amcheck before running amdump. My script, which is run from > crontab, checks to see if amcheck ran successfully before I allow amdump to > run. I'm using samba to back up Windows servers across the network to my > Sun server. Is there any good reason to have this type of procedure in > place where amcheck must be successful before running amdump? > > Also, I don't run amverify either because I lack the time during the backup > window for this. I'm not sure this is necessary either. What is amverify > really checking? I don't think it checks what was dumped on tape vs what is > on the disk. Is it necessary to make sure you really have a valid backup? > > Bob... > > -- > Robert Zahn UNIX Systems Administrator > Oklahoma City Community College > S. May Avenue > Oklahoma City, Ok 73159 > [EMAIL PROTECTED][EMAIL PROTECTED] > --
Re: amcheck - why run it?
Making amdump conditional on amcheck doesn't make sense. In particular, you probably want amdump to run and dump to holding disk if there is no tape, and if even 1 host is up you probaly want that host backed up. I would expect that on configs with 100 clients that a typical night involves a client timing out. As long as it's a different client every night, that's no problem - if you run amdump anyway. amverify is useful to see that bits can be read back from the tape. It isn't a full restore test (for that, pick a random employee and have then pick an important file, and go get that and present it to them for validation), but it mostly checks that your tape drive can read bits back, especially if you gzip. The dump files are uncompressed and run through restore to verify format. I had a tape drive or scsi bus fail such that most of bits were right but there was a lot of corruption. one could read files back, and most of them had gzip failures. We replaced the tape drive, and the problem has not recurred. But, we run amverify once a week (on the weekend, using hte tape from Friday night's dump) to verify that we aren't having a similar problem. So, you really should do a test restore once a week. But if you, like most humans, don't, then a weekly amverify is a good idea. -- Greg Troxel <[EMAIL PROTECTED]>
Re: amcheck - why run it?
On Tue, Sep 23, 2003 at 05:23:30PM -0400, Greg Troxel wrote: > ... . But, we run amverify once a week (on the > weekend, using hte tape from Friday night's dump) to verify that we > aren't having a similar problem. > > So, you really should do a test restore once a week. But if you, like > most humans, don't, then a weekly amverify is a good idea. I like that idea. Think I'll implement it. Not having used amverify, how do you handle a backup that used multiple tapes? Do you need an intelligent script to determine which tapes were used that day? And then run amverify on each? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amcheck - why run it?
Jon LaBadie <[EMAIL PROTECTED]> writes: > Not having used amverify, how do you handle a backup that > used multiple tapes? Do you need an intelligent script > to determine which tapes were used that day? And then > run amverify on each? I only write one tape per day, so I hadn't thought about this. But the point is to verify that some tape, picked more or less arbitrarily from the week, is ok, to ensure that the bits that amanda thought she wrote to tape can be read back. So at 0005 every Tuesday to Saturday (Monday to Friday night), we run amdump. Just after midnight on Sunday (Saturday night), we run amverify, which reads the tape that is still in the drive from Friday night's dump. Or, if the tape didn't get changed, Thursday night's dump. So, we make no attempt to verify any particular tape. The hope is that if the tape drive starts corrupting bits, we'll notice it. It would be better to run amverify in a different tape drive, to verify that we would have a chance of reading tapes if we lost the drive and had to get a replacement. -- Greg Troxel <[EMAIL PROTECTED]>
Re: amcheck - why run it?
We run amcheck once before end of business day to ensure the (right) tape is in. Our back-up script also runs amcheck, but doesn't use it to determine whether to run amdump. Instead it uses it to determine whether to do a verify and eject the tape. If amcheck does not exit 0 just before amdump is run, then the tape isn't verified or ejected so that we can better deal with the issue in the morning. The reason why we want amdump to run anyway is that we at least want partial disk dumps. --a On Tue, 2003-09-23 at 14:09, Bob Zahn wrote: > Lately, with the advent of some network viruses, I've had backups not occur > when I run amcheck before running amdump. My script, which is run from > crontab, checks to see if amcheck ran successfully before I allow amdump to > run. I'm using samba to back up Windows servers across the network to my > Sun server. Is there any good reason to have this type of procedure in > place where amcheck must be successful before running amdump? > > Also, I don't run amverify either because I lack the time during the backup > window for this. I'm not sure this is necessary either. What is amverify > really checking? I don't think it checks what was dumped on tape vs what is > on the disk. Is it necessary to make sure you really have a valid backup? > > Bob... > > -- > Robert Zahn UNIX Systems Administrator > Oklahoma City Community College > S. May Avenue > Oklahoma City, Ok 73159 > [EMAIL PROTECTED][EMAIL PROTECTED] > -- -- Albert Hopkins <[EMAIL PROTECTED]> Laboratory Corporation of America - IMPORTANT WARNING: This e-mail and any files transmitted with it may contain CONFIDENTIAL information, including PRIVATE AND CONFIDENTIAL HEALTH INFORMATION which is intended for the use of the person to whom it is addressed. If the reader of this e-mail/attachment is not the intended recipient, employee, or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, reproduction, reading, or copying of this information is STRICTLY PROHIBITED. If you have received this e-mail in error, please delete the related e-mail and all attachments and notify the sender immediately (reply e-mail) and the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722.
Re: amcheck - why run it?
Hi, Bob Zahn, on Dienstag, 23. September 2003 at 21:09 you wrote to amanda-users: BZ> Also, I don't run amverify either because I lack the time during the backup BZ> window for this. I'm not sure this is necessary either. What is amverify BZ> really checking? I don't think it checks what was dumped on tape vs what is BZ> on the disk. Is it necessary to make sure you really have a valid backup? Currently I run amverify after every amdump. My backup window leaves me enough time to do that and so I have "amverified" that the tapes I wrote are at least readable. At the particular installation amverify takes ~30-60 minutes (DDS-3 tapes) depending on tape usage. I would recommend doing amverify at least once a week to detect tape errors before it is too late. Doing amverify on another tape-drive, as Greg assumes, would be even better, but exceeds the budget of my customers ... As I am not in place that often, I would like to have some automated amrecover-run that restores some files of the actual tape. So it would be like: 1500 amcheck 2200 amdump && amverify && automated_amrecover I think about including a small DLE containing testfiles, which is dumped full every run and can be used to be recovered via a script. Has anyone done something like that? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amcheck - why run it?
On Thu, Sep 25, 2003 at 02:53:52PM +0200, Stefan G. Weichinger wrote: > > Currently I run amverify after every amdump. My backup window leaves > me enough time to do that and so I have "amverified" that the tapes I > wrote are at least readable. At the particular installation amverify > takes ~30-60 minutes (DDS-3 tapes) depending on tape usage. > > I would recommend doing amverify at least once a week to detect tape > errors before it is too late. Doing amverify on another tape-drive, as > Greg assumes, would be even better, but exceeds the budget of my > customers ... > > As I am not in place that often, I would like to have some automated > amrecover-run that restores some files of the actual tape. > > So it would be like: > > 1500 amcheck > 2200 amdump && amverify && automated_amrecover > > I think about including a small DLE containing testfiles, which is > dumped full every run and can be used to be recovered via a script. > > Has anyone done something like that? Similar to a question I asked Greg, have you any idea how to handle a multiple tape backup situation? What if the DLE you want to test was on the first tape of several used that day? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amcheck - why run it?
On Thu, Sep 25, 2003 at 09:38:03AM -0400, Jon LaBadie wrote: > > Similar to a question I asked Greg, have you any idea how to handle > a multiple tape backup situation? What if the DLE you want to test > was on the first tape of several used that day? Duh ... now I can respond to my own question to Greg. Because I read the man pages finally :( I asked Greg how you could do a amverify after a multi-tape amdump. I.e. how you would figure out which tapes to verify? NAME amverify - check an Amanda tape for errors SYNOPSIS amverify config [ slot [ runtapes ] ] DESCRIPTION . . . If config is set up to use a tape changer, the slot argument may be used to choose the first tape to process. Otherwise, the current slot is used. The runtapes configuration parameter determines how many tapes are processed unless it is specified on the command line. Ahh, it will do multiple tapes. So I just have to figure out how many and where to start. Then I read further ... SEE ALSO amrestore(8), amanda(8), amverifyrun(8) Hmmm, "amverifyrun", never saw that one before. Wonder what that is? NAME amverifyrun - check the tapes written by the last amanda run SYNOPSIS amverifyrun config DESCRIPTION Amverifyrun read the log from the last amanda run to find the slot of the first tape used and the number of tapes used. It call amverify with these argument. Gee, someone already thought about that problem and the solution? It's in there Feeling silly, sorry for the noise. jon -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amcheck - why run it?
Hi, Jon, on Donnerstag, 25. September 2003 at 15:57 you wrote to amanda-users: JL> Gee, someone already thought about that problem and the solution? JL> It's in there JL> Feeling silly, sorry for the noise. Never mind, we all come to that RTFM over and over again ;-) -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amcheck - why run it?
on Donnerstag, 25. September 2003 at 15:57 you wrote to amanda-users: JL> Gee, someone already thought about that problem and the solution? JL> It's in there JL> Feeling silly, sorry for the noise. Never mind, we all come to that RTFM over and over again ;-) And in any case ... now *I* don't have to go through the same several steps you used to find the answer. Thank you very much for posting the solution to the list!!! amverifyrun -- who'da thunk it? Kewl! Deb Baddorf --- Deb Baddorf [EMAIL PROTECTED] 840-2289 "Nobody told me that living happily ever after would be such hard work ..." S. White<
Re: amcheck - why run it?
This is to thank everyone that responded to the original posting. General consensus is that you run amchecks late in the afternoon, check e-mail, fix any problems before you go home. For amverify, most run this on the weekend or after the last backup of the week has completed. But a better recommendation is to weekly test a restore process to really make sure it works. As for myself, I'll run amcheck in the afternoon and try to remember to check e-mail before I leave for the day and run amverify on the weekends. As far as testing a restore, I'll do this on weekends or holidays when I have other work scheduled. There's this perception by end-users and management that our systems should be available 24x7x365. Just a side note - I am now backing up 2 Sun servers and 24 Windows NT/2000 servers. Just after I had Amanda working for a couple of weeks, a WebCt administrator deleted several online courses from the server in error. Of course, she had no backup copies. Latest backup from the network group was almost a week old (best they could do was a weekly backup). I had just backed up this server the day before. I used gnutar to restore the backup to disk and then used amrestore to restore the files that were deleted to the server. The bag of candy kisses from the WebCT admin was greatly appreciated. Bob... > Bob, > > I don't run amdump dependent on amcheck output - amdump can fail > quite well on its own. > > Lately, with the advent of some network viruses, I've had backups not occur > > when I run amcheck before running amdump. My script, which is run from > > crontab, checks to see if amcheck ran successfully before I allow amdump to > > run. I'm using samba to back up Windows servers across the network to my > > Sun server. Is there any good reason to have this type of procedure in > > place where amcheck must be successful before running amdump? > > > > Also, I don't run amverify either because I lack the time during the backup > > window for this. I'm not sure this is necessary either. What is amverify > > really checking? I don't think it checks what was dumped on tape vs what is > > on the disk. Is it necessary to make sure you really have a valid backup? > > > > Bob...
Re: amcheck - why run it?
Jon LaBadie <[EMAIL PROTECTED]> writes: > I asked Greg how you could do a amverify after a multi-tape amdump. > I.e. how you would figure out which tapes to verify? > NAME > amverifyrun - check the tapes written by the last amanda run > > SYNOPSIS > amverifyrun config > > DESCRIPTION > Amverifyrun read the log from the last amanda runto find > the slotof the first tape used and the number of tapes > used. It call amverify with these argument. This seems to assume that the tapes are in consecutive slots. (amverify seems to have this limit, and amverifyrun does not work around this.) Sven
Re: amcheck - why run it?
On Sun, Sep 28, 2003 at 05:42:02PM +0200, Sven Rudolph wrote: > Jon LaBadie <[EMAIL PROTECTED]> writes: > > > I asked Greg how you could do a amverify after a multi-tape amdump. > > I.e. how you would figure out which tapes to verify? > > > NAME > > amverifyrun - check the tapes written by the last amanda run > > > > SYNOPSIS > > amverifyrun config > > > > DESCRIPTION > > Amverifyrun read the log from the last amanda run to find > > the slot of the first tape used and the number of tapes > > used. It call amverify with these argument. > > This seems to assume that the tapes are in consecutive > slots. (amverify seems to have this limit, and amverifyrun does not > work around this.) > As amverifyrun is simply a shell script that calls amverify telling it the number of tapes, it is not surprising that it would suffer the same defects. Is there a way, other than "amtape ... show" to get a list of the tapes currently in the changer? I'd like to think there was an alternative to going through each slot individually unless necessary. I can imagine a way to modify amverifyrun to call amverify to do specific slots one at a time. However, it would take knowledge of what tapes are in the changer. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amcheck - why run it?
Jon LaBadie <[EMAIL PROTECTED]> writes: > On Sun, Sep 28, 2003 at 05:42:02PM +0200, Sven Rudolph wrote: > > This seems to assume that the tapes are in consecutive > > slots. (amverify seems to have this limit, and amverifyrun does not > > work around this.) > > > > As amverifyrun is simply a shell script that calls amverify telling > it the number of tapes, it is not surprising that it would suffer > the same defects. > > Is there a way, other than "amtape ... show" to get a list of the > tapes currently in the changer? I'd like to think there was an > alternative to going through each slot individually unless necessary. > > I can imagine a way to modify amverifyrun to call amverify to do > specific slots one at a time. However, it would take knowledge of > what tapes are in the changer. IMHO "amtape label" should be sufficient. So you only need the labels of the tapes that were written today. Then you can insert them with "amtape label". (This needs some kind of barcode support (real or emulated).) Sven
Re: amcheck - why run it?
On Tue, Sep 30, 2003 at 03:59:41PM +0200, Sven Rudolph wrote: > Jon LaBadie <[EMAIL PROTECTED]> writes: > > > On Sun, Sep 28, 2003 at 05:42:02PM +0200, Sven Rudolph wrote: > > > > This seems to assume that the tapes are in consecutive > > > slots. (amverify seems to have this limit, and amverifyrun does not > > > work around this.) > > > > > > > As amverifyrun is simply a shell script that calls amverify telling > > it the number of tapes, it is not surprising that it would suffer > > the same defects. > > > > Is there a way, other than "amtape ... show" to get a list of the > > tapes currently in the changer? I'd like to think there was an > > alternative to going through each slot individually unless necessary. > > > > I can imagine a way to modify amverifyrun to call amverify to do > > specific slots one at a time. However, it would take knowledge of > > what tapes are in the changer. > > IMHO "amtape label" should be sufficient. So you only need the labels > of the tapes that were written today. Then you can insert them with > "amtape label". (This needs some kind of barcode support (real or > emulated).) Ahh, another of those commands and options I did not realized existed. Never had a barcode reader nor used a changer script that emulated one. :(( Might be a reason to switch to one. Does chg-zd-mtx "effectively", in peoples opinions, emulate one? I.e. does it maintain a list of tapes and use it to randomly go to the correct slot with "amtape label tape-name" If so, I may take a shot at updating amverifyrun. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
