Avatar billede lojmann Nybegynder
24. februar 2005 - 14:59 Der 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?

Jeg køre det på en Debian maskine!

/Thomas
Avatar billede lap Nybegynder
24. februar 2005 - 17:08 #1
kender ikke BackupPC, men /dev/st0 er dit tapedrev. Hvis har en eller flere dumpfiler, så kan tar cfv /dev/st0 <dumpfiler> skrive til dlt
Avatar billede gozar Nybegynder
24. februar 2005 - 17:29 #2
Kig også på mt for at styre selve båndet
Og her http://www.eksperten.dk/spm/582383
Avatar billede lojmann Nybegynder
25. februar 2005 - 15:03 #3
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 er et DLT drev med et 80/160GB bånd i!
Avatar billede janpo Nybegynder
25. februar 2005 - 16:08 #4
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
Avatar billede gozar Nybegynder
25. februar 2005 - 16:14 #5
>> tar czvf /dev/st0 /mappe-der-skal-gemmes

Jeg ville nok fjerne "f" da det jo ikke er en fil der skal gemmes i :-)
Avatar billede janpo Nybegynder
25. februar 2005 - 16:28 #6
/dev/st0 er en fil.
Avatar billede gozar Nybegynder
25. februar 2005 - 17:38 #7
Er du nu helt sikker på det er en fil?

gozar@ $ stat /dev/st0
  File: `/dev/st0'
  Size: 0              Blocks: 0          IO Block: 4096  character special file
Device: 302h/770d      Inode: 704743      Links: 1    Device type: 9,0
Access: (0660/crw-rw----)  Uid: (    0/    root)  Gid: (  26/    tape)
Access: 2004-08-03 01:30:36.000000000 +0200
Modify: 2001-04-15 02:43:43.000000000 +0200
Change: 2004-08-03 01:30:36.000000000 +0200
Avatar billede janpo Nybegynder
26. februar 2005 - 09:52 #8
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
Avatar billede lojmann Nybegynder
26. februar 2005 - 16:45 #9
Jeg vender lige tilbage på mandag (håber jeg) når jeg kommer tilbage på arbejdet :)
Avatar billede lojmann Nybegynder
28. februar 2005 - 16:27 #10
Nu skete der noget, hvordan ser jeg hvad der er på mit DLT og hvordan får jeg hentet det ud igen?
Avatar billede lojmann Nybegynder
01. marts 2005 - 14:00 #11
Skriver: tar -xzvf /dev/st0

Den pakker en del ud men så skriver den;

tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers

gzip: stdin: invalid compressed data--crc error

gzip: stdin: invalid compressed data--length error
tar: Read 132 bytes from /dev/st0
tar: Child returned status 1
tar: Error exit delayed from previous errors


Den restore ikke alt det den skal kun den første mappe!
Avatar billede lap Nybegynder
01. marts 2005 - 15:22 #12
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
Avatar billede lojmann Nybegynder
02. marts 2005 - 08:40 #13
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 :)

Mange tak for hjælpen!
Avatar billede lap Nybegynder
02. marts 2005 - 09:00 #14
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"

Husk igen blocking-factor.
Avatar billede lap Nybegynder
02. marts 2005 - 09:01 #15
du kan også restore hele mapper med ./root/*
Avatar billede lojmann Nybegynder
03. marts 2005 - 16:25 #16
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!
Avatar billede lap Nybegynder
04. marts 2005 - 08:53 #17
sæt " rundt om filnavnet/ene, men jeg svarer i aften hvor jeg har eksempel på restore.
Avatar billede lap Nybegynder
04. marts 2005 - 18:58 #18
Her er opskriften:

tar --extract --verbose --blocking-factor 256 --file /dev/st0 "mnt/backup/Users/_rod/*"

Husk at restore foregår relativt i forhold til hvor du står - så hvis du står i /root vil mappen /root/mnt/backup/Users/_rod blive oprettet.
Avatar billede lojmann Nybegynder
10. marts 2005 - 13:20 #19
Vil du også foreslå at jeg smider --blocking-factor 256 på når jeg tager min backup? For det er noget værre vrøvl den kan restore...
Avatar billede lap Nybegynder
10. marts 2005 - 13:41 #20
Ja, du skal skrive og læse med samme blokcking factor - det er for ikke at "rive" båndet i stykker - og for at optimere skrivehastigheden.
Avatar billede lojmann Nybegynder
23. marts 2005 - 15:22 #21
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 er ved at være lost :(
Avatar billede lap Nybegynder
23. marts 2005 - 17:06 #22
drop "z" i backup og restore - det er ingen god ide at pakke data på vej frem og tilbage til tapedrev.
Avatar billede lojmann Nybegynder
25. marts 2005 - 17:31 #23
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...

Noget bud på hvorfor den gør som skrevet ovenfor?

/Thomas
Avatar billede lojmann Nybegynder
25. marts 2005 - 21:29 #24
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 :)

God påske herfra, vender tilbage næste uge :)
Avatar billede lap Nybegynder
26. marts 2005 - 10:30 #25
drevet komprimerer formentlig selv - det er sikkert et 50/100 er 35/70 drev, så behøver du ikke at komprimere.

Formentlig kommer OS og bånd ud af sync under læsningen - derfor fejlen.

Der er ingen grund til at være bekymret over "delayed" fejl - har set den mange gang uden problemer.
Avatar billede lojmann Nybegynder
04. april 2005 - 08:09 #26
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 :/

Mon der findes et alternativ til tar?
Avatar billede lap Nybegynder
04. april 2005 - 21:06 #27
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.
Avatar billede lojmann Nybegynder
04. april 2005 - 21:55 #28
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 :)

/Thomas
Avatar billede lap Nybegynder
05. april 2005 - 08:26 #29
Point er nu ikke vigtige.

Kan man forestille sig, at tar "går amok" pga. "dårlige tegn" - f.eks. ü, æøå osv.?
Avatar billede lojmann Nybegynder
05. april 2005 - 10:10 #30
Hmmm det var en mulighed!

Der er også %-tegn i alle filer og mapper i mit original data...Hmm... Jeg prøver sku lige at tage en mappe kun med a-z og 0-9 tegn i...
Avatar billede lojmann Nybegynder
14. april 2005 - 14:04 #31
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... :(

/Thomas
Avatar billede lap Nybegynder
14. april 2005 - 23:23 #32
jeg plejer at bruge: cpio -ova > /dev/st0 og cpio -imudv < /dev/st0 (og kontrol med cpio -itv < /dev/st0).

tar man liste filer med tar tfv /dev/st0
Avatar billede lojmann Nybegynder
19. april 2005 - 09:05 #33
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... :/
Avatar billede lap Nybegynder
19. april 2005 - 09:07 #34
blocking factor
Avatar billede lojmann Nybegynder
19. april 2005 - 13:27 #35
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?
Avatar billede lap Nybegynder
19. april 2005 - 13:54 #36
Ram skulle ikke være noget problem - der bruges ikke noget ram for at bruge cpio - der er igen noget galt.

Kontroller lige, at /dev/st0 er et special device og ikke en fil - måske er din disk løbet fuld (check evt. med df -h)
Avatar billede lojmann Nybegynder
19. april 2005 - 14:00 #37
Der er plads nok på disken... /dev/st0 er en device mig bekendt, lavede lige en "ls -al | grep st0" og så kom denne:

crw-rw----  2 root tape      9,  0 Sep 18  2004 st0
Avatar billede lap Nybegynder
19. april 2005 - 14:46 #38
ok, men ram-meldingen kan nemlig også betyde, at det er slut på diskplads.
Avatar billede lojmann Nybegynder
19. april 2005 - 15:52 #39
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.
Avatar billede lap Nybegynder
19. april 2005 - 21:25 #40
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.
Avatar billede lojmann Nybegynder
26. april 2005 - 08:29 #41
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!

Hjælp inden jeg smider hele lortet i havnen :)

/Thomas
Avatar billede lap Nybegynder
26. april 2005 - 18:00 #42
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?
Avatar billede lojmann Nybegynder
27. april 2005 - 09:36 #43
Nu har jeg prøvet med 64, 128 og 256 som blocking factor, men hver gang kommer der fejl - samme type fejl.

Her er forløbet. Linier der starter med # er den kommando der er skrevet for at få det efterfælgende output.

#dump 0nbf 64 /dev/st0 /home/tlj/test-data
  DUMP: Date of this level 0 dump: Wed Apr 27 08:48:49 2005
  DUMP: Dumping /dev/hdc1 (/ (dir home/tlj/test-data)) to /dev/st0
  DUMP: Label: /
  DUMP: Writing 64 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 7816636 blocks.
  DUMP: Volume 1 started with block 1 at: Wed Apr 27 08:49:48 2005
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 47.65% done at 12415 kB/s, finished in 0:05
  DUMP: 89.00% done at 11595 kB/s, finished in 0:01
  DUMP: Closing /dev/st0
  DUMP: Volume 1 completed at: Wed Apr 27 09:01:49 2005
  DUMP: Volume 1 7812992 blocks (7629.88MB)
  DUMP: Volume 1 took 0:12:01
  DUMP: Volume 1 transfer rate: 10836 kB/s
  DUMP: 7812992 blocks (7629.88MB) on 1 volume(s)
  DUMP: finished in 645 seconds, throughput 12113 kBytes/sec
  DUMP: Date of this level 0 dump: Wed Apr 27 08:48:49 2005
  DUMP: Date this dump completed:  Wed Apr 27 09:01:49 2005
  DUMP: Average transfer rate: 10836 kB/s
  DUMP: DUMP IS DONE






#restore tbfy 64 /dev/st0
Dump  date: Wed Apr 27 08:48:49 2005
Dumped from: the epoch
Level 0 dump of / (dir home/tlj/test-data) on npdev:/dev/hdc1
Label: /
Checksum error 236631, inode 835629 file <directory file - name unknown>
Missing blocks at the end of <directory file - name unknown>, assuming hole
        2      .
    688129      ./home
  6815769      ./home/tlj



#restore rvbfy 64 /dev/st0
(en masse fejl som den vist herunder)
cannot find directory inode 835629
Check the symbol table.
Check pointing the restore
Avatar billede lojmann Nybegynder
27. april 2005 - 09:37 #44
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...
Avatar billede lap Nybegynder
28. april 2005 - 21:28 #45
Du er sikker på, at dit DLT-drev er i orden - og alt er termineret korrekt?
Avatar billede lojmann Nybegynder
22. juli 2005 - 13:22 #46
Nu virker det, ser ud til at terminieringen var forkert. Beklager det sene svar! Tak for hjælpen til alle!
Avatar billede Ny bruger Nybegynder

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.

Loading billede Opret Preview
Kategori
IT-kurser om Microsoft 365, sikkerhed, personlig vækst, udvikling, digital markedsføring, grafisk design, SAP og forretningsanalyse.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester