24. februar 2005 - 14:59Der er
45 kommentarer og 1 løsning
Backup af filer til DLT drev på Linux
Hej,
Jeg køre pt backup med BackupPC på min linux boks, men jeg vil gerne smide mine dumps ud på DLT bånd automatisk hver nat, når BackupPC er færdig med sin backup.
Er der nogle der har erfaringer med dette og kan hjælpe mig lidt på vej mod en løsning?
Når jeg køre en "mt status" får jeg flg. besked - betyder det mon at den ikke ved hvad det er for en tape? Tænker på linien med "Tape block size"
drive type = Generic SCSI-2 tape drive status = 1342177280 sense key error = 0 residue count = 0 file number = 0 block number = 0 Tape block size 0 bytes. Density code 0x50 (unknown). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN
Det ville jeg "springe op og falde ned på". Det har jeg rent faktisk gjort i al den tid jeg har brugt LTO bånd. Prøv fra CLI at se om det virker. Hvis det gør, så bruger du bare crontab til at lave en tar hver nat. Piece of cake :-) 00 02 * * * tar czvf /dev/st0 /mappe-der-skal-gemmes
Helt nøjagtigt er det en device-fil. Af charcter type. Men for tar ser det ud som enhver anden fil. Det er et hook ind i kernen, som gennem modulet st.o (eller st.ko hvis du kører 2.6) kommunikerer med din båndstation. Faktum er, at tar samler mapper/filer i en fil og du putter det i /dev/st0 hvilket medfører at det bliver skrevet ned på dit bånd. Læs evt. her http://www.tldp.org/LDP/lame/LAME/linux-admin-made-easy/server-backup.html#TAR-BACKUP
prøv at lave være med at komprimere: tar cfv /dev/st0 <filer> og tar xfv /dev/st0
Derudover kan dit problem være, at du ikke angiver en anden blokstørrelse, således at båndet bliver "flået" i stykker (tar har en default blocksize på 20k) - prøv med "man tar" at atgive en større blokstørrelse - f.eks. 256Kb
Så virkede det, jubii... Men det ærger mig lidt at man ikke (ser det ud til) at man kan restore bare enkelte filer men at man skal restore hele lortet, det kan jo tage pænt lang tid at fremskaffe bare et enkelt dokument eller et sæt soruce koder, hvis der skal restores 50GB...
Er der nogle der ved om man kan restore kun enkelte filer? (det kan man vel ikke, når der ikke er et fs på dlt'en?)
lap, janpo og gozar - hvis i 3 lige poster et "svar" så deler jeg point ud :)
Jo, du kan godt restore enkelte filer. Du skriver formentlig med "relativ" path (altså ./root/fil.txt i din skrivelog) - så kan du restore med tar xfv /dev/st0 "./root/fil.txt"
Hmm... Jeg har prøvet at restore enkelte ting - der sker flg.
npdev:~/test# tar xvf /dev/st0 ./mnt/backup/Users/_rod/ tar: This does not look like a tar archive tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Archive contains `\212\330\323\355:h\310q%E\341[' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `7*\264\223\272\3050\200\2241\240' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\260#\370\004\016\246j\270\275\266sw' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\372\220sp\261RV*\360))\207' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\201=%3W\345\350\357\314\355J]' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `/\374\0258\231?\006Nq\207\377\210' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\004d0\031\263\005\223m\022\250\016\026' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\031z\032f\203\\\363JVd\325M' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `f\016\257\237\027f\236\000\301\303\300\227' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\357\225\030\3378\256\003|K\227\261\341' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\341\263\275\232g\026#\267nA\034h' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\301\340\324\257\354m\360\254\237,\204e' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\325\233\344j5\016\345Nu\177 8' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\230\355=\361%`m\252qhuc' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\305\354\034K\006XF~\304\377&z' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `5_T\244\032\216\356\204k\340.' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `3\353\256,\265l6\223\275\312\376' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `_\225+\2235I\034\375\003P\304P' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `n\025A5\017l\250\250\363\352\225\016' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `@?s\215~\366.\375\334\3025\372' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\257\236\203V\360\375\006\341=5\332\372' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `qwr\000\355\037\257G\246\340\344\355' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\312\374\354\346\376&q`\205\034\035\022' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\000c\034\264\265-\'\033\345(\310' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `j|\223u\205\215\372\267\234\256x\320' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `P\203?\346o\034?\377\263)\253V' where numeric off_t value expected tar: Skipping to next header tar: Archive contains `\250\315q\304\363\361\231\036\216\315\a6' where numeric off_t value expected tar: Skipping to next header tar: ./mnt/backup/Users/_rod: Not found in archive tar: Error exit delayed from previous errors
Jeg har lige prøvet at starte det igen med kommandoen:
tar xvf /dev/st0 ./mnt/backup/Users/_rod/*
for at se om det hjælper, men jeg tvivler... jeg ved 100% at den fil findes!
sorry for at det har taget en krig, men der har lige været lidt travlt...
Nu er jeg kommet så langt, har leget med backup og restore til den helt store guldmedalje men det spiller sku ikke helt med den skide restore! :(
backup: tar czvf /dev/st0 --blocking-factor 256 /var/log/
restore: tar -xzvf /dev/st0 --blocking-factor 256
MEN under restore kommer flg. error msg.:
tar: Skipping to next header tar: Archive contains obsolescent base-64 headers
gzip: stdin: invalid compressed data--format violated tar: Read 32768 bytes from /dev/st0 tar: Child died with signal 13 tar: Error exit delayed from previous errors
Jeg har prøvet både med og uden "--blocking-format 256" men der sker det samme hvergang desværre.
Jeg har nu fjernet den option (z) fra det hele, er ellers ked at af skulle undvære komprimering - men det må jeg leve med ser det ud til.
Dog er det stadig ikke helt optimalt, den kommer med denne fejl når jeg skal rulle backup retur:
tar: Error exit delayed from previous errors
Jeg tænkte på om det kan være fordi der liggern oget på båndet i forvejen (køre altid en "mt rewind" før backup og restore) at den fejler?
Jeg sætter en "mt erase" igang på den og må komme tilbage senere og kigge (sidder på en træls modem forbindelse laaangt fra arbejde og hjem), for så at tage backup af f.eks. 5-10 filer som jeg kan huske og så se om alt er ok - men vil jo helst have den ikke giver nogle som helst form for fejl...
Hmmm... efter en "mt erase" og så endnu et forsøg (dog med nye filer som jeg tog backup af og restorede igen) virkede det.
Jeg vil kigger lidt nærmere på det når jeg kommer på arbejde på tirsdag - for at se om de entledige data som skal smides på DLT og måske restores igen nu også virker.
Det er filer fra backuppc som skal smides på DLT'er, så regner ikke med at jeg nogle sinde skal bruge mine DLT'er men de skal være der... HVIS NU :)
Hmmm... Nu har jeg arbejdet med det rigtige data, efter jeg fik mit test til at virke. Test data var bare på ca. 500 mb, så man ikke skal vente hele natten på at lege med det og rette fejl!
Nu har jeg prøvet flere gange med det rigtige data, som er cirka 50gb, og det er noget værre sludder den smider ud på båndet! Filnavne bliver omdøbt, filstruktur efter en restore er ikke den samme og der er rigtig meget galt :/
tar er den mest brugte kommando til ditribution af filer, så det virker meget usansynligt, at det ikke virker. Tar bliver også brugt til rigtige backups masser af steder - helt uden problemer.
Men jo, der findes alternativer. Cpio er den mest oplagte, men da cpio og tar virker stort set ens, så er det formentlig et dårligt valg.
Kommandoen dump bruges til at dumpe hele partitioner, så det er næppe et godt alternativ.
Du kunne prøve at kikke på amanda - har ikke selv brugt det, men er client/server baseret - og formentlig et alternativ.
Amanda har jeg set på tidligere, det er ikke et brugbart alternativ - desværre.
Cipo håber jeg at få tid til at se på imorgen, det var et af de to alternativer jeg tænke på. Kan ikke huske hvad det andet hed, det var noget jeg læste mig til.
Har en ide til hvorfor min TAR går sådan amok, det skal jeg lige se om holder og hvordan jeg løser.
Selvom problemet ikke er løst endnu, syntes jeg at du - lap - har været en stor hjælp, så de 30 point er dine uanset hvad :)
Jeg har nu prøvet cpio som jeg syntes rigtig godt om, men jeg har et problem med at restore!
Backup af mappe (som "man står i"): find . -print | cpio -ovH crc -O /dev/st0
Backup virker fint, jeg kan også trække en liste ud med filer og det er rigtig lækkert. Men når jeg skal restore igen, så vil den ikke!
Jeg bruger flg. kommando: cpio -icvmuld -I /dev/st0
Den restore ikke, den printer bare hjælpe teksten. Jeg har kigget i man pages og på nettet, den syntax skulle være ok men den vil ikke... Er der mon noget jeg har overset?
Jeg har også prøvet med "cpio -icvdBum < /dev/st0" men så spoler den bare båndet igennem og spytter det ud igen... Det kan jeg ikke rigtig bruge til noget... :(
Prøvede backup til DLT'en, cirka 86GB data - satte den igang cirka kl. 18 igår, og den var måske nåede 10% idag her til morgen... Det kan jo ikke bruges, vi skal jo have dags backup også.
Er der mon en en grund til at det tager så lang tid, jeg mener - TAR smed det på hurtigere, men ok - det virkede godt nok heller ikke altid... :/
Så kom tingene på tape, ser det ud til.. nu vil jeg så lave en kontrol, men så siger den at der ikke er memory nok, det undre mig en del. Der er 1GB ram i maskinen, den køre en pgsql, mysql, apache 1.3, apache 2 og et par andre småting - ikke noget som andre og mindre maskiner har problemer med.
Hvad kan der være galt?
Når jeg vil restore igen, er det ikke andet end vrøvel! block-size=256 satte jeg på, skal jeg ændre den? 512 eller 1024?
Der er diskplads nok. Det som den restore inden den stopper, det er noget vrøvl. F.eks. restore den filer og mapper med navne ala "%#"%re¤%?=?=0" ol. det giver jo ingen mening. De filer som den skal tage backup af, ligger i et specialt fil-dir, lavet af backuppc.
F.eks. kunne dette være en path til nogle filer: /var/lib/backuppc/pc/localhost/8/f%2fetc%2f/ og de mapper er der rigtig mange af, mon det er det der %f2 som den bare ikke kan lide? Det er noget BackupPC generer. Filerne virker perfekt, via BackupPC etc.
Det er overvejende sansynligt, at alle de specialtegn ikke kan accepteres af tar/cpio. Desværre kan jeg godt forestille mig, at du vil få problemer med mange/de fleste programmer, som er filbaserede.
Jeg har ikke nogen løsingsmodel til dig - dump er nok eneste kommando (i hvert fald eneste jeg lige kan komme i tanke om) som du kan bruge.
Hmm... Nu har jeg prøvet 117 forskellige ting med dump og restore, men samme problem som med de andre. Blocking-factor tror jeg!
npdev:/home/tlj/test# restore tbfy 1024 /dev/st0 Dump date: Mon Apr 25 11:50:38 2005 Dumped from: the epoch Level 0 dump of / (dir home/tlj/test-data) on npdev:/dev/hdc1 Label: / Checksum error 220175, inode 98318 file <directory file - name unknown> Checksum error 243736, inode 147610 file <directory file - name unknown> Checksum error 237736, inode 868452 file <directory file - name unknown> Missing blocks at the end of <directory file - name unknown>, assuming hole 2 . 688129 ./home 6815769 ./home/tlj
etc...
Er der regler for det? For jeg har prøvet flere forskellige uden at det virker, det er samme fejl/problemer hver gang og jeg er ved at gå helt i spåner over det.
Jeg har forsøgt at google mig til mere info om blocking-factor men kan ikke finde noget der kan bruges syntes jeg!
Sidst jeg teste dette, så fandt jeg ud af, at nye drev kan tåle en blockingfacktor på op til 256 - herefter går performance ned igen - nogle drev kører samme performance på 128 og 256.
Du er sikker på, at dit DLT-drev er i orden - og alt er termineret korrekt?
Glemte at skrive, der bliver opretten en mappe, home, som er tom (min data mangler) og så på samme nivue som den mappe ligger en fil "restoresymtable" som ikke fylder alverden (7-8mb) men mine data mangler...
Nu virker det, ser ud til at terminieringen var forkert. Beklager det sene svar! Tak for hjælpen til alle!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
