Continuing problem with mixed Windows/Unix backups
Hi all, I’ve written in about this before, but I have yet to find a satisfactory answer and am hoping someone has a solution. I have a Red Hat based Amanda server and mostly Red Hat Amanda clients with the exception of a few Windows 7 systems running the ZManda Community Windows Client. Everything works great until one of the Windows hosts is unavailable during backups. If that happens, not just that host will fail but other hosts (not all, but at least half or so) will also fail to back up properly. I can even see this problem when running an “amcheck”. If I comment out the problem Windows host from the disk list, I see no errors. However, if I leave the host in the disk list, I get errors about a number of our Linux clients like: WARNING: foo.eecs.utk.edu: selfcheck request failed: error sending ACK: write error to: Broken pipe Note, this only happens when a Windows system is having problems, not if any of the Linux systems is down or otherwise unavailable when the backups run. I made sure to upgrade everything to 3.3.6 but that doesn’t seem to have fixed things. Does anyone have the same experience? Thanks, Markus --- Markus A. Iturriaga Woelfel, IT Administrator Department of Electrical Engineering and Computer Science University of Tennessee Min H. Kao Building, Suite 424 / 1520 Middle Drive Knoxville, TN 37996-2250 mitur...@eecs.utk.edu / (865) 974-3837 http://twitter.com/UTKEECSIT
Re: Backups to tape consistently under 60% tape capacity
The hardware was just over a year old. Even IBM commented on the usage hours being very low. Very surprising to have it go bad when so young. t. On 06/12/14 04:16, Debra S Baddorf wrote: Wow. How old was the hardware? I had the impression it was newish. Just curious. Deb On Dec 4, 2014, at 11:19 PM, Tom Robinson tom.robin...@motec.com.au wrote: Hi, Just to tidy off this thread, the hardware was at fault. We got a new HBA in the process as we thought tape performance may have been affected by sharing an HBA with disks. It turns out that the real issue was that the tape unit itself was faulty (and it had damaged one tape - or was it the tape that damaged the unit?). With the support of IBM, we updated the firmware of both the library and tape drive but after several tests showed no improvement, IBM shipped a replacement drive SLED. I now get the native capacity on the tape as expected. Kind regards, Tom On 20/10/14 10:49, Tom Robinson wrote: Hi, I'm not sure why I'm not getting such good tape usage any more and wonder if someone can help me. Until recently I was getting quite good tape usage on my 'weekly' config: USAGE BY TAPE: Label Time Size % DLEs Parts weekly013:10 1749362651K 117.91616 weekly023:09 1667194493K 112.42121 weekly033:08 1714523420K 115.51616 weekly043:04 1664570982K 112.22121 weekly053:11 1698357067K 114.51717 weekly063:07 1686467027K 113.72121 weekly073:03 1708584546K 115.11717 weekly083:11 1657764181K 111.72121 weekly093:03 1725209913K 116.31717 weekly103:12 1643311109K 110.72121 weekly013:06 1694157008K 114.21717 For that last entry, the mail report looked like this: These dumps were to tape weekly01. Not using all tapes because 1 tapes filled; runtapes=1 does not allow additional tapes. There are 198378440K of dumps left in the holding disk. They will be flushed on the next run. Which was fairly typical and to be expected since the tune of flush settings was: flush-threshold-dumped 100 flush-threshold-scheduled 100 taperflush 100 autoflush yes Now, without expectation, the dumps started to look like this: weekly023:21 1289271529K 86.91010 weekly033:17 854362421K 57.61111 weekly043:20 839198404K 56.61111 weekly059:40 637259676K 42.9 5 5 weekly06 10:54 806737591K 54.41515 weekly091:1235523072K2.4 1 1 weekly093:21 841844504K 56.71111 weekly013:16 842557835K 56.81919 About the time it started looking different, I introduced a second config for 'archive' but I can't see why that would affect my 'weekly' run. I had a couple of bad runs and had to flush them manually and I'm not sure what happened with tapes weekly07 and weekly08 (they appear to be missing) and weekly09 is dumped to twice in succession. This looks very weird. $ amadmin weekly find | grep weekly07 2014-09-14 00:00:00 monza /data/backup/amanda/vtapes/daily/slot4 0 weekly07 1 1/-1 PARTIAL PARTIAL $ amadmin weekly find | grep weekly08 2014-09-14 00:00:00 monza /data/backup/amanda/vtapes/daily/slot4 0 weekly08 1 1/-1 PARTIAL PARTIAL $ amadmin weekly find | grep weekly09 2014-09-21 00:00:00 monza / 0 weekly09 9 1/1 OK 2014-09-21 00:00:00 monza /data/backup/amanda/vtapes/daily/slot1 0 weekly09 10 1/1 OK 2014-09-21 00:00:00 monza /data/backup/amanda/vtapes/daily/slot2 0 weekly09 11 1/-1 OK PARTIAL 2014-09-14 00:00:00 monza /data/backup/amanda/vtapes/daily/slot4 0 weekly09 1 1/1 OK 2014-09-14 00:00:00 monza /data/backup/amanda/vtapes/daily/slot5 0 weekly09 2 1/1 OK 2014-09-14 00:00:00 monza /data/backup/amanda/vtapes/daily/slot6 0 weekly09 3 1/1 OK 2014-09-14 00:00:00 monza /data/backup/amanda/vtapes/daily/slot7 0 weekly09
Re: moving amanda backups to a new tape format
Am 05.12.2014 um 00:33 schrieb Debra S Baddorf: I’ve only got a year’s worth of data on LTO2 tape, so this seems worth doing. I had older yet SDLT tapes before that, lots of them. Those I won’t try to convert, but will save the heroics until someone absolutely requires some old data. Learning a little about AMVAULT wouldn’t hurt me either, so this seems like a worthwhile project. Me too. I'd like to learn more about amvault to get more confident in setting up two-step-setups: pull in stuff via amanda ... backup to vtapes first ... then archive stuff to tapes every month ... as an example. Stefan
Re: Continuing problem with mixed Windows/Unix backups
Does this involve mixing the type of authentication: BSD, BSDTCP, KRB5, (do other types exist? ) Are your Linux systems all using the same type of authentication? What does a Windows client have to use? I’m having similar problems when my Linux nodes are down, because some of them are using different types of authentication from the older nodes.I don’t know if the problem would go away if all nodes were at modern BSDTCP or KRB5 , but right now, my older BSD-only nodes choke if a newer node is offline. I too went to 3.3.6 and found no relief.I’ve gotten sidetracked from trying to fix the code myself. Deb Baddorf Fermilab On Dec 10, 2014, at 4:08 PM, Markus Iturriaga Woelfel mitur...@eecs.utk.edu wrote: Hi all, I’ve written in about this before, but I have yet to find a satisfactory answer and am hoping someone has a solution. I have a Red Hat based Amanda server and mostly Red Hat Amanda clients with the exception of a few Windows 7 systems running the ZManda Community Windows Client. Everything works great until one of the Windows hosts is unavailable during backups. If that happens, not just that host will fail but other hosts (not all, but at least half or so) will also fail to back up properly. I can even see this problem when running an “amcheck”. If I comment out the problem Windows host from the disk list, I see no errors. However, if I leave the host in the disk list, I get errors about a number of our Linux clients like: WARNING: foo.eecs.utk.edu: selfcheck request failed: error sending ACK: write error to: Broken pipe Note, this only happens when a Windows system is having problems, not if any of the Linux systems is down or otherwise unavailable when the backups run. I made sure to upgrade everything to 3.3.6 but that doesn’t seem to have fixed things. Does anyone have the same experience? Thanks, Markus --- Markus A. Iturriaga Woelfel, IT Administrator Department of Electrical Engineering and Computer Science University of Tennessee Min H. Kao Building, Suite 424 / 1520 Middle Drive Knoxville, TN 37996-2250 mitur...@eecs.utk.edu / (865) 974-3837 http://twitter.com/UTKEECSIT
Re: Continuing problem with mixed Windows/Unix backups
Once amanda completely hung for me and the log said getting estimate on one of the hosts, it was caused by a hung NFS mount. My clients are all Red Hat so I'm not sure about the Windows client. Perhaps a samba issues? Steve -- Steven J. BackusComputer Systems Manager University of Utah E-Mail: steven.bac...@utah.edu Genetic EpidemiologyAlternate: bac...@math.utah.edu 391 Chipeta Way -- Suite D Office: 801.587.9308 Salt Lake City, UT 84108-1266 http://www.math.utah.edu/~backus
