Problemen met backuppen

[Verwijderd]

We hebben de laatste tijd een raar probleem met het backuppen.
We draaien altijd ieder weekend een full backup van onze RAID schijf
en iedere werkdag ('s avonds) een incremental backup. Dat ging altijd
goed maar de laatste tijd worden backups niet afgemaakt om een voor ons
onbekende reden.
In het logboek van "windows 2000 advanced server" is dan de volgende melding
terug te vinden:

type: error
source: adpu160m
eventid: 9
description: the device, \device\scsi\adpu160m1, did not respond within the timeout period.

Soms komt daar de volgende melding achteraan:

type: warning
source: disk
eventid: 51
description: an error was detected on device \device\harddisk1\dr1 during a paging operation.

Het backuppen gebeurd met "ARCserver 2000 advanced edition 7.0" alle data word op tapes gezet. De fullbackup word met een autoloader gedaan waar 4 tapes in kunnen. De incremental backup word met een gewone tapestreamer gedaan waar 1 tape in kan.
We gebruiken de volgende hardware:
RAID: Arena-II Ultra2 LVD SCSI-to-IDE RAID
met daarin Seagate schijven (U6 model ST360020A, 60GB)
Autoloader: Sony AIT-2 SCSI extern
De SCSI lijn is als volgt:
De RAID zit aan de SCSI-controller van de server. Aan de RAID zit de autoloader. Aan de autoloader zit de single tapestreamer met daaraan een terminator.

Heeft iemand al eens een dergelijk probleem gehad? En nog beter, weet iemand een oplossing?
Alvast bedankt voor de hulp.

[Spoooky]

Hij kan niet meer goed schrijven naar de unit, heb je in arcserve geen SCSI-timeouts??

[Verwijderd]

ARCserve zelf geeft ook errors in de logs ja. Alleen kan ik nu even niet kijken welke errors omdat de server op de zaak staat. Had ik er even bij moeten zetten

[Spoooky]

SCSI timeouts kan je SCSI kaart zijn. Je kan het zeker nit met een andere unit/kabel proberen???

[Verwijderd]

We hebben ook een backup server waarin dezelde hardware zit als de server die nu draaid.
Ik heb samen met mijn collega de SCSI controller van de hoofdserver omgewisseld met die van de backupserver. Gewoon om eens te kijken of het probleem daar in zat. Maar dat bleek niet de oplossing te zijn. Zou het soms kunnen dat er breuken in de SCSI kabels zitten?
Met "backup server" bedoel ik overgens een extra server die ingezet kan worden als de hoofdserver de geest geeft.

[ Voor 15% gewijzigd door Verwijderd op 25-07-2003 16:59 ]

[Verwijderd]

Echt niemand die weet waar dit aan kan liggen?

[Spoooky]

maar even om duidelijkheid te krijgen: Welke meldingen geeft arcserve prcies in zijn log?
Als het timeouts zijn zou inderdaad de kabel de boosdoener kunnen zijn..

[richard_kraal]

laat me raden, tapesteamer zit samen met de raid disks op dezelfde kanaal/controller

[Spoooky]

Ze hebben toch wel allemaal een ander SCSI ID (disks enz tapeunit)?

[Verwijderd]

de RAID, autoloader en tapestreamer zitten alle 3 op de zelfde SCSI lijn ja. Ze hebben uiteraard wel een verschillende ID

[richard_kraal]

Verwijderd schreef op 28 July 2003 @ 12:59:
de RAID, autoloader en tapestreamer zitten alle 3 op de zelfde SCSI lijn ja. Ze hebben uiteraard wel een verschillende ID

ik heb daar zoveel problemen mee gehad, dat moet je NOOIT doen, HP/DELL etc adviseren dan ook om hem op een aparte controller te doen!!!

probeer een losse scsi kaart te pakken

[Verwijderd]

De errors die in ARCserver staan zijn deze:

Error 3714

3714 Unable to write to media. (MEDIA=media_name, EC=media_error_code)

Module:
Tasks Engines

Explanation:
ASTASK cannot write to the specified media.

Cause/Solution:
Check the error code. Check that the media is in the proper storage device. The media may be damaged or the storage device's heads may need cleaning.

en deze:

6300 Windows NT SCSI PORT Error

Module:
Media Engine

Explanation:
Problem with sending a SCSI command to SCSI device.

De tapes op een apparte scsi-kaar zetten lijkt mij geen gek idee.
Ik zal het zeker voorleggen.

[Spoooky]

als je een SCSI-kaart hebt liggen, probeer dan die tapeunit daar aan te hangen. en kijken hoe het werkt. Heb je geen rare meldingen/performanceproblemen met de schijven???

[Verwijderd]

Met de RAID heb ik geen problemen. Het moet in de tapestreamers zitten.
Ik zal eerst proberen om de tapestreamer die aan het uiteinde van de scsi-lijn
zit er af te halen en eens kijken of dat het probleem oplost. (de tapestreamer is
ondertussen al wat jaartjes oud) Als dat geen verbetering geeft ga ik proberen
om de tapestreamers op een aparte scsi-kaart te zetten.
Moet ik nog bepaalde dingen doen (bijv. apparaten verwijderen in windows)
of kan ik de tapestreamer er zo afhalen en de terminator op de autoloader
zetten?
Wel vreemd trouwens. We hebben 1,5 jaar probleemloos backups gemaakt met
deze opstelling. Dat zou je toch kunnen stellen dat het wel moet kunnen om
de RAID en de tapestreamers op dezelfde scsi-lijn te zetten.

[Stalkert]

Incremental backuppen met ArcServe? Kan dit dan? En zo ja hoe?

[Verwijderd]

Jazeker, hoe het precies moet weet ik niet want mijn collega
doet de backups. Hij heeft het me wel eens laten zien hoe hij
de backups altijd maakt maar dan is alweer een tijdje geleden
Ik wil het wel even voor je nakijken.

[Domino]

error 3714 op support.ca.com

Kort samengevat : Tape kapot/versleten of tapedrive cleanen.

Weet niet of het de goede oplossing is, maar er is zat te vinden op die errorcode. Kijk zelf maar eens op support.ca.com of groups.google.com

@stalkert

Stalkert schreef op 29 July 2003 @ 10:42:
Incremental backuppen met ArcServe? Kan dit dan? En zo ja hoe?

Je kan in Arcserve gewoon een rotation job instellen. Naar keuze met elke dag een full of incremental backup.

[ Voor 32% gewijzigd door Domino op 29-07-2003 12:57 ]

[Verwijderd]

De tapestreamers schoonmaken hebben we al geprobeerd maar dat heeft niets geholpen. Andere tapes maken ook niks uit. Maar evengoed bedankt voor de links, die kende ik nog niet en ze lijken me erg handig.

[Xiphalon]

is de tape niet gewoon vol?

[Verwijderd]

Nee, jammer genoeg niet. Dan was het probleem gauw opgelost

[Verwijderd]

Ik heb gisteravond de tapestreamer die aan het einde v/d scsi-lijn zat er af gehaald en een fullbackup aangezet op de autoloader. Nu kreeg ik in ARCserve weer dezelfde error, nl error 3714
In het logboek van windows 2000 is weer dezelfde adpu-melding te vinden.

Dan zit het probleem misschien toch in de autoloader. Vannavond gaan we
die eraf pakken, het tapestreamertje weer terugzetten en dan weer een
fullbackup proberen. Betekent wel dat we steeds tapejes moeten wisselen
Maar goed, dat kunnen we tenminste wel uitproberen in welk device de fout
nu echt zit.

[ Voor 33% gewijzigd door Verwijderd op 30-07-2003 09:22 ]

[Kosh66]

Als ik zo de Windows foutmelding lees, dan genereerd de Ultra160-controller of een van de SCSI-disken een timeout bij het opnieuw opkomen na een standby/resume uit de powersave-mode.

Ik heb dit ook gehad met een IBM-disk, deze spint heel traag op. Dit soort errors kreeg ik altijd na het wakker worden van het systeem uit de standby/Powersave-mode.

Deze heb ik dan ook maar subiet uitgezet. Het systeem draait nu zonder standby/powersave mode (i.i.g. de disken op de SCSI-chain dan).

[Xiphalon]

Heb je al ALLE tapes een keer vervangen? tzou ook kunnen zijn dat er ergens een brakke tape tussen zit, waardoor je tapedrive reset en je raid-controler de draad kwijtraakt.

Ondersteunt je RAID controller zowieso wel dat er een tape op zit? (Tape-pass-through)?? Welke is het eig?

Zonder directe ondersteunig werkt het meestal wel, maar krijg je idd dit soort errors.

Daarnaast, een cleaning tape werkt maar een paar (stuk of 5) keer! daarna is vervanging ervan nodig.

[Verwijderd]

Voor zover ik kan nagaan staat geen enkele schijf in de powersave modus en kan dus ook niet in de standby stand terecht komen.
Wat wel het geval is, is dat er sinds kort 2 schijven in de RAID zitten die niet van hetzelfde type zijn als de schijven die er altijd inzaten. Er zitten nu dus 6 schijven van type-A in en 2 schijven van type-B. De enige overeenkomst tussen de schijven is de capaciteit (60GB)
We waren er eigenlijk helemaal niet blij mee dat dat gebeurde maar de schijven van type-A waren niet meer te leveren (wat achteraf weer niet waar bleek te zijn want de laatste schijf die we hebben bijbesteld om reserve te houden is weer van type-A)
Zou dat de timeouts kunnen veroorzaken? Of werken er hier meer mensen met een RAID waar verschillende schijven inzitten.

[SPee]

Wanneer treden die foutmeldingen op?
Is het elke keer wanneer je een back-up maakt, of 1 keer als je een speciale back-up maakt. (waarbij je steeds dezelfde tape gebruikt).

Ik heb ook wel een keer een melding gekregen dat hij niet kon schrijven en dat bleek aan de tape te liggen. Nou was de tapedriver ook brak (heel oud ), dus hebben we uiteindelijk een nieuwe drive (en tapes) gekocht. Maar die drive is best wel een dure grap.

[Verwijderd]

De fouten treden volkomen willekeurig op. Soms al voordat een een backup nog moet beginnen. Soms halverwege, aan het begin of aan het einde van een backup. En (heel) soms helemaal niet.
Er is echt geen pijl op te trekken

[u_nix_we_all]

Klink als scsi bus termination probleem.

[Verwijderd]

Ik heb nu maar een pc gepakt en daar 2 schijven van 120GB ingehangen. Daarna ben ik 's avonds alles via een netwerkverbinding alles van de RAID naar deze pc toe gaan pompen. Ik heb nu in iedergeval een gedeelte kunnen backuppen en een lijst met wat er wel en wat er niet is gebackupped.
En wat denk je? in het logboek van windows zijn nu weer exact dezelfde adpu/disk meldingen te vinden. Het probleem zit blijkbaar in de RAID. Overgens ben ik ook bad blocks op de RAID tegen gekomen. Hopelijk ben ik nu wat dichter bij de oplossing.
Weet iemand of het mogelijk is om te achterhalen welke van de 8 schijven in de RAID badblocks heeft?

[Verwijderd]

Toen we verder zijn gegaan met het backuppen via een netwerkverbinding zijn er 2 schijven van de RAID stuk gegaan (eerst 1 schijf, later ook de spare schijf waarmee de RAID aan het rebuilden was) Terwijl deze 2 schijven uitgeschakeld stonden werden er nog steeds bad blocks en corrupte files op de RAID gevonden.
Met ander woorden, er zijn nog meer schijven verrrot.
We kunnen nu dus wel stellen dat het probleem in de RAID zit.
Eigenlijk heeft die het, nu we er over nadenken, nog nooit goed gedaan. Voordat deze problemen begonnen kwam het regelmatig voor dat er een schijf uitviel. Het ding vreet gewoon schijven. Schijven die stuk gaan zijn overgens ook echt stuk. Het is dus niet zo dat de RAID ze onterecht uitschakelt. Ze worden gewoon vernield.
Heeft iemand dit ook al eens meegemaakt? Zo ja, waar lag het aan?

[Verwijderd]

Ok, het probleem is waarschijnlijk opgelost. Het moet uiteraard in de praktijk nog bewezen worden maar het ziet er iig goed uit allemaal.

Het probleem is waarschijnlijk veroorzaakt door het gebruik van een verkeerde terminator. Er zat altijd een oude terminator op de single tapestreamer. Waarschijnlijk is die in de loop v/d tijd gewoon versleten. Het probleem begon ook af en toe op te treden maar werd hoe langer hoe erger. Nadat we de single tapestreamer hebben afgekoppeld werd het probleem nog erger (veel meer "disk" meldingen in het logboek van windows) Later kwamen we erachter dat er op de autoloader een andere terminator moest (nadat we de single tapestreamer hadden afgekoppelt zat de autoloader aan het einde van de lijn) Dat werkte in principe goed, alleen wisten we dat niet. Immers, de corrupte data bleef (die was ontstaan doordat het systeem een tijdje gedraaid heeft met een verkeerde, veel te zwakke, terminator op de autoloader)
We hebben toen ook de autoloader afgekoppeld en in onze RAID softwarematige termination aangezet. Dit bleek ook niet te werken want de "disk" meldingen bleven maar komen. We wisten echter nog steeds niet dat het aan foute termination lag (de softwarematige termination v/d RAID bleek niet voldoende te zijn)
Uiteindelijk zijn, op advies van de leverancier en de fabrikant, alle schijven v/d RAID vervangen. Dat bleek dus ook niet de oplossing te zijn.
Na nog wat bellen met maxtronic (fabrikant van onze RAID) kwamen we op het punt termination. Toen kwam pas naar voren dat de softwarematige termination v/d RAID niet voldoende bleek te zijn (ik denk dat dat alleen gebruikt kan worden als de RAID aan het einde v/d scsi-lijn zit en de weerstand v/d terminator minder sterk hoeft te zijn)
Het hebben toen zsm de server weer plat gelegd, de softwarematige termination uitgeschakeld en gewoon een hardwarematige terminator op de RAID gezet (een LVD/SE terminator, die was geschikt volgens de fabrikant)
Daarna een checkdisk gedraaid die nog flink wat currupte data recht gezet heeft.
Nu lijkt alles weer normaal te draaien. Als we de RAID flink laten zweten door wat grote kopieer opdrachten aan te zetten blijven de "disk" meldingen uit. Met verkeerde termination ging dat dus vreselijk fout.

Nog even een melding die wel interessant is om te weten. de zgn "disk" meldingen in het logboek waren in werkelijkheid "cyclic redundency check errors" (schrijf ik dat goed? ) Oftewel currupte files en zeker geen bad blocks.

Mocht iemand dus een soortgelijk probleem tegenkomen, begin dan met het kopen van een nieuwe terminator, het kan je een hoop ellende besparen.
Verder werd ons, door maxtronic, het advies gegeven om regelmatig het lcd scherm van de RAID in de gaten te houden. Als er namelijk schijven aan vervanging toe zijn dat word dat daar op aangegeven. Verder ervoor zorgen dat er regelmatig een checkdisk gedraaid wordt.
Wat we tijdens een zoektocht op internet tegen kwamen, corrupte data word in de meeste gevallen veroorzaakt door verrot geheugen. Mocht het hele termination verhaal dus niet werken dan weet je waar je verder moet zoeken.

Hopelijk worden hier mensen mee geholpen, dit is namelijk niet leuk om mee te maken. Het was voor mijzelf wel erg leerzaam trouwens

[ Voor 4% gewijzigd door Verwijderd op 07-08-2003 11:37 ]

[Verwijderd]

Nou, we dachten het probleem opgelost te hebben. Niet dus, na afgelopen weekend was het hele logboek weer lekker volgebaggerd met de gevreesde "adpu" en "disk" meldingen. Een andere terminator heeft er trouwens wel voor gezorgd dat de problemen minder erg zijn geworden maar blijkbaar is er nog meer niet goed.
We hebben nu maar een 1:1 kopie van de c-schijf v/d server gemaakt (met norton ghost 2003) en die image op onze backup server geknalt. Daarna de RAID aan de backupserver geknoopt en de boel weer gestart. Dat draaid nu al een weekje zo en het lijkt goed te gaan. Er zijn iig geen meldingen meer bijgekomen. Blijkbaar is het geheugen van onze hoofdserver niet goed meer en zorgde dat voor corrupte files. Maar dat is nu een probleem dat ik op m'n gemak uit kan gaan zoeken

[ Voor 3% gewijzigd door Verwijderd op 15-08-2003 08:48 ]