testdrive op intel server (backup werkt niet)

[hjo]

HI,
Ben bezig met een testdrive van een syn3 business versie op een intel single xeon server.
Ziet er allemaal heel goed uit, bravo.
Klein maartje!
Gebruik een usb hp 72GB DAT voor backup.
Wordt netjes herkend als ik hem inplug, en aan st0 toegewezen.
Echter bij het maken van een backup gaat er iets mis, de drive start en doet een rewind/retensing.
En dan stop hij zonder 1 bit geschreven te hebben.
Logfie meldt:

knip
Data van /usr/backup/postgres.backup naar /home/system/spool
Data van /usr/backup/quota.backup naar /home/system/spool
/usr/backup/quota.backup: line 2: xfsdq: command not found
Data verzamelen van /usr/backup/quota.backup mislukt!
knip

Na enkele minuten stopt de drive de tape weer in de cassette, om verder te zwijgen.

Alarm status: Backup/restore   Backup sessie naar syn3_W47D01_1164060764 voortijdig afgebroken!

Syn-3 versie:
B-21082006-1240-v3.0-build2618M met alle updates

enig idee ?

[erwin]

Beste Hendik,

Binnenkort zal er support zijn voor dit type DAT USB tape drive. Op dit moment werken alleen de scsi tape backup units.

Er is reeds een USB DAT tape drive ter test aanwezig.

[hjo]

hi,

Alvast wat hints voor als je aan de slag gaat.
De drive wordt tijdens het starten van het systeem niet herkent.
Dit omdat scsi voor usb opgebracht wordt, als je de unit uit en in plugt na boot wel (hotplugger).
Dit is niet praktisch.
een 'hotplug tape.agent' na de boot werkt beter.
moet wel eerst een /etc/init.d/hotplug restart doen (?huh?).

xfsdq ontbreekt op mijn systeem ( niet in de distributie?)

Als ik dit even uithek # in het script, loopt de procedure iets verder maar struikeld verderop.

INFO:xfsdump: estimated dump size: 164385280 bytes
INFO:xfsdump: /var/lib/xfsdump/inventory created
INFO:xfsdump: preparing drive
INFO:xfsdump: WARNING: media may contain data. Overwrite option specified
INFO:xfsdump: WARNING: no media label specified
INFO:xfsdump: dump size (non-dir files) : 0 bytes
INFO:xfsdump: NOTE: dump interrupted: 1 seconds elapsed: may resume later using -R option
INFO:xfsdump: Dump Status: INTERRUPT
Probleem tijdens deze sessie!
STAT:Backup sessie voortijdig afgebroken!
INFO: (backup op tape word niet verwijderd)

spit nog even verder.

[erwin]

Hendik,

Als je iets gevonden hebt dan graag een post. Ik ga hier komende week mee aan de slag.

[hjo]

hallo,

ik zie spoken geloof ik.

ik zie in een versie file dat de distro slackware 10.0 gebruikt is voor syn3?

die distro heeft xfsdq niet meer aan boord ook slack 11 niet. ( mogelijk vanwege een veiligheids probleem, schrijven naar file via standard out in de root van het systeem).
Er schijnt een nieuwe versie te zijn.
waar komt die van syn vandaan?
maar in denieuwe versie kan dit niet werken 'xfsdq -g /home -f $1/group.quotas || exit 1' in /usr/backup/quota.backup.

ergo sum.

backup kan niet werken met welke drive dan ook!

Dan xfsdump.

Die struikeld met een read error.

xfsdump -v drive=debug,media=debug -f /dev/st0 /

geeft deze fout:

knip
tape positioned at BOT: doing redundant rewind
xfsdump: tape op: rewind 0
xfsdump: tape op: get status
xfsdump: tape status = bot onl
xfsdump: tape op: reading 1048576 bytes
xfsdump: tape op: get status
xfsdump: tape status = onl
xfsdump: ERROR: unexpected tape error: errno 16 nread -1 blksz 1048576 recsz 1048576 isvar 1 wasatbot 1 eod 0 fmk 0 eot 0 onl 1 wprot 0 ew 0
xfsdump: ERROR: unexpected error from do_begin_read: 10
xfsdump: dump size (non-dir files) : 0 bytes
xfsdump: NOTE: dump interrupted: 6 seconds elapsed: may resume later using -R option
xfsdump: Dump Status: INTERRUPT

maar een tar naar dezelfde tape werkt wel!

tar -cvvf /dev/st0 /home

dusssssss.... er is iets mis met xfsdump.

morgen verder

[erwin]

Hendik,

ik ben er nog niet mee bezig geweest maar even een korte reactie.

het commando om te backuppen is volgens mij xfsdump.

Het gene waar ik in eerste instantie naar ga kijken is de blksz (blocksize). Ik verwacht persoonlijk dat de fout hier in zit.

We zijn ooit begonnen met Syn-3 vanuit Slackware 10.0, daarom staat die file er ook nog in. Deze kun je voor de rest ignoren.

[edwin]

xfsdq is niet meer nodig, doordat we een nieuwere versie van xfsdump gebruiken. Errors hierover kun je negeren, en dit zal bij de volgende update van het backup systeem verholpen zijn. Deze error kan verder geen kwaad, de backup gaat wel gewoon door.

Het echte probleem zit hem in een combinatie tussen xfsdump en de usbtape driver. Hier gaat erwin ook nog naar kijken deze week. Je zou inderdaad wat kunnen proberen met bloksizes. Ook de dmesg output kan bruikbare error-informatie geven in zon geval.

Edwin

[hjo]

helder....

Het is dus de nieuwe versie xfsdump en die heeft xfsdq niet meer nodig, maar staat nog wel in het script.

blocksize, daar zat ik vandaag ook aan te denken.

dmesg meld een blocksize 'st0: Block limits 1 - 16777215 bytes'

volgens hp moet je een minimale blocksize van 65k aanhouden, maar zeggen zij 'the bigger the better'.
Dit vanwege de performance.

xfsdump neemt standaard 1mb als blocksize en dat werkt niet!

maar dit werkt wel:

xfsdump -F -l 0 -o  -b 65536 -v drive=debug,media=debug -f /dev/st0 /home

een block size van 65kb dus.

verschillende andere getest zoals 128kb en 256kb en 512kb.

alleen 65kb werkt.
xfsdump: dump size (non-dir files) : 163208784 bytes
xfsdump: dump complete: 28 seconds elapsed
xfsdump: Dump Status: SUCCESS

nu even voor proef het script /usr/backup/backup aanpassen

       elif [ $mode == "tape" ]; then
                xfsdump -L "$FILE" -o  -b 65536 -p 10 -F -f $TAPEDEV $DUMPMNT || terminated
        else
                echo "Backupmode $mode is onbekend!";
                terminated

en yes!!! het werkt!!

dus hieruit conludeer ik dat deze tapestreamer (hp shurestore 72GB usb) alleen werkt als je een blocksize van 65kb meegeeft, dus niet aan de defaults overlaten.

nu nog het usb detectie probleem na boot oplossen.

[hjo]

soms kan het leven heel simpel zijn.

postboot 'modprobe usb_storage' uitvoeren.

en ziedaar de tapedrive aan st0

Dus.... /etc/rc.d/rc.modules aangepast.

Bij de usb sectie '/sbin/modprobe usb_storage' toevoegen en klaar.

Nu wordt de Tapesteamer wel in de boot herkend.

Ergo Sum

het werkt !!!!!!!!!!

[erwin]

Hendik,

Bedankt dat je het al even uitgezocht hebt, dan kunnen wij het nog sneller implementeren.

Ik zal er voor zorgdragen dat dit heel snel gebeurd.

Met vriendelijke groet,

Erwin

[edwin]

Hendik,

Bedankt voor de informatie!
We zullen het systeem aanpassen zodat dit gaat werken.
Als je nog meer suggesties op tips hebt horen we het graag.

Mag ik vragen waarvoor je Syn-3 straks wilt gaan gebruiken? Is het voor eigen gebruik, of ben je geintereseerd om dealer/reseller van Syn3 te worden?
(hier kun je een informatie pakket voor aanvragen bij ons)

Edwin

[hjo]

Hoi,

Om een of andere rede ben je gebonden aan die 65kb, er zit ergens een bottle neck, maar goed het werkt zo prima en is mee te leven.
Het implementeren is een ander probleem, want botweg die parameter aanpassen zullen niet alle soorten tapestreamers leuk vinden.
hint: je kunt met 'lsusb' zien wat voor tapestreamer er aan de usb bus hangt.

Ik bouw servers die in het MKB gebruikt worden, tot nu toe deed ik dat op SuSe distributies, Samba, postfix, cyrus, Apache, softraid etc.....
Maar door de nieuwe koers die zij nu varen onder aanvoer van novell ben ik er niet meer gelukkig mee.
De kleine distributie hebben ze in een .org ondergebracht en alle updates van voor 9.3 van de servers gemikt.
Juist diekleine distributie heeft hen groot gemaakt, want daar zitten de gebruikers met kennis.
En die worden nu zoetgehouden in een .org, en dan zelf zeker gaan lopen met de goed ideeen en oplossingen.
Mijns inziens, als rechtgeaarde open source man, een slechte ontwikkeling in de linux wereld.
Ze zijn daar wel heel erg commercieel aan het worden, en voor het MKB onbereikbaar (lees onbetaalbaar).
Affijn, de ratten verlaten niet voor niets het zinkende schip.
Dus maar eens uit gaan kijken naar iets anders, maar om nou het wiel weer opnieuw uit te gaan vinden?

Een paar jaar geleden heb ik met jullie in Tiel zitten bomen over hoe je zelf een veilige, snelle en goed te onderhouden server distributie zou moeten maken.
Alles wat je niet gebruikt overboord, en alleen beproefde onderdelen gebruiken, geen toeters en bellen.

Ik had toen een syn-3 home meegekregen (een van de eerste cd's), die had ik indertijd binnen een halve dag overstuur.
Maar ook ik weet, een goede wijn heeft zijn tijd nodig.
Dus maar weer eens een verse versie opgehaald.
En moet zeggen, ziet er goed uit.
En OX 8.2 bied nu serieuze mogelijkheden, ga hem binnenkort eens met dolox uitproberen.

zodoende

[edwin]

Ik denk dat we dat probleem met die 65k eerst oplossen, door dit instelbaar te maken in de SCC, met suggesties voor enkelle waarden. (niet invullen betekend dan weer auto-detectie)

Ten opzichte van een jaar geleden heeft Syn-3 een aantal grote systeem verbeteringen meegemaakt waaronder:
-betere scheiding van apache, SCC en openxchange
-nieuwste versie van de meeste software
-overgang van 2.4 kernel/devfs naar 2.6/udev
-verbeterde opstart procedure
-grub bootloader in plaats van lilo
-grub bootloader op cdrom
-alle product versies op cdrom
-eigen ontwikkeld systeem voor volledige transparante redundancy (via drbd) Hiervoor zijn geen apparte scripts/truucs nodig zoals normaal wel het geval is bij bijvoorbeeld heartbeat.

De volgende grote verbeteringen zijn nog in opkomst:
-Mogelijkheid om netwerkzones aan andere netwerk kaarten te kopellen.
-Compleet vernieuwd registratie en licentie systeem
-Home editie gratis
-Bepaalde sources en ontwikkeltools GPL maken zodat derden kunnen meewerken aan ontwikelling syn-3.
-Omgeving en apache geschikt maken voor extra webapplicaties en intranet websites.

Dit zijn de echte grote wijzigigen, hiernaast zijn we natuurlijk altijd bezig met extra features en applicaties.
Deze grote wijzigingen zijn nodig om Syn-3 gereed te maken voor de komende jaren.

Het is bij Syn-3 zelfs mogelijk om vlekkeloos te upgraden van OX 8.0 naar OX 8.2. Dit was zelfs bij de commerciele OX server versie niet mogelijk voor zover ik weet.

Zoals je weet is Syn-3 speciaal gericht op het MKB, dus ik denk dat je zult zien dat ons product hier inmiddels zeer geschikt voor is.

Edwin

[hjo]

Ja, dat zou een snelle oplossing zijn.
Je zou kunnen laten zien welke tapestreamer er in het systeem gevonden is voor extra info.
kennelijk gaat het fout met devices met een variabele block size.

Ja, ziet er goed uit, ik merk het verschil met de eerste versie.
En een home editie maken en mensen mee laten ontwikkelen en denken is denk ik een goede stategie.
Het bouwen van een ldap paraplu is ook een leuke optie.
vraag me alleen af of je niet in de problemen komt als je overal syn-3 als root doain gaat gebruiken.

Wat me nog aan ox dwars zit is, geen koppeling naar je eigen home dir.
Dat zo leuk zijn.

Dan kun je 'binnen' met samba een compleet windows domein draaien.
En 'buiten' mensen via ox laten werken.

Dan hoef je dat domein niet over een vpn te sleuren, wat overigens niet echt goed werkt bij smalle verbindingen.

En het is veiligheids technisch beter, je hoeft maar een paar poorten open te zetten naar binnen, en hebt niet echt een vpn verbinding nodig.
je zou al af kunnen met b.v. een secure client.

Dan wordt het aankoppelen van een pda of ander mobile werkstaton een fluitje van een cent.

Ach ja,... zo blijven we aan het werk en van de straat.

Dat dealer pakket had ik al aangevraagd begin van de week, zie wel mogelijkheden.

[edwin]

Inderdaad die OX optie zou leuk zijn. We hebben inmiddels wel ftp en secure ftp, zodat men naar de homedir kan.

Bedankt voor de verdere informatie