|
|
 | Hjælp med forslag til en linux serv
Fra : Allan Madsen |
Dato : 27-09-05 10:49 |
|
Hejsa
Jeg vil gerne have en linux server op at stå, den skal kun funger som
fil server for et vindows netværk og som mail henter (fetchmail??).
Den skulle gerne kører noget raid (sata)? med f.eks 160Gb disk plads.
Desuden skal der en tape streamer i. (Rigtige mænd er begyndt at tage
backup *g*)
Der er intet krav til noget grafisk, og det er kun ca 5 windows klienter
der skal koble op mod den.
Har i nogle forslag til hviken hardware der skal i for at det hele kan
spille sammen??
Og hvilken backup software der vil være godt at kunne kører på den???
MVH
Allan Madsen
| |
 Hans Joergensen (27-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 27-09-05 10:54 |
|
Allan Madsen wrote:
> Jeg vil gerne have en linux server op at stå, den skal kun funger som
> fil server for et vindows netværk og som mail henter (fetchmail??).
> Den skulle gerne kører noget raid (sata)? med f.eks 160Gb disk plads.
> Desuden skal der en tape streamer i. (Rigtige mænd er begyndt at tage
> backup *g*)
Du burde overveje at tage backup på harddiske, det er nemmere,
billigere og imho mere stabilt.
personligt foretrækker jeg at synkronisere til en anden maskine via
netværk (evt. over internet, afhængig af datamængden).
> Der er intet krav til noget grafisk, og det er kun ca 5 windows klienter
> der skal koble op mod den.
> Har i nogle forslag til hviken hardware der skal i for at det hele kan
> spille sammen??
Hm, i teorien kan du nok nøjes med en hvilkensomhelst standard PC,
evt. med lidt ekstra køling i form af nogle blæsere.
> Og hvilken backup software der vil være godt at kunne kører på den???
rsync, kørt via cron.
// Hans
--
http://www.dkfritidmotorcykel.dk/Hans_Joergensen
| |
Kent Friis (27-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-05 15:50 |
|
Den 27 Sep 2005 09:54:08 GMT skrev Hans Joergensen:
> Allan Madsen wrote:
>> Jeg vil gerne have en linux server op at stå, den skal kun funger som
>> fil server for et vindows netværk og som mail henter (fetchmail??).
>> Den skulle gerne kører noget raid (sata)? med f.eks 160Gb disk plads.
>> Desuden skal der en tape streamer i. (Rigtige mænd er begyndt at tage
>> backup *g*)
>
> Du burde overveje at tage backup på harddiske, det er nemmere,
> billigere og imho mere stabilt.
Hvad koster en kasse med 10 hotplug-harddiske (nok til 10 ugentlige
backups)?
Hvad koster en æske med 10 bånd?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
 Klaus Ellegaard (27-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 27-09-05 16:15 |
|
Kent Friis <nospam@nospam.invalid> writes:
>Den 27 Sep 2005 09:54:08 GMT skrev Hans Joergensen:
>Hvad koster en kasse med 10 hotplug-harddiske (nok til 10 ugentlige
>backups)?
Vi snakker 160 GB. Vi ved ikke helt, hvad det er, så vi må antage,
at vi snakker 160 GB ukomprimerbart.
200 GB One-Touch + 9 x 200 GB diske = 6.931 kr.
>Hvad koster en æske med 10 bånd?
LTO2-drev + SCSI-fjæs + 10 x LTO2-bånd = 18.755 kr.
Mvh.
Klaus.
| |
Kent Friis (27-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-05 16:27 |
|
Den Tue, 27 Sep 2005 15:14:35 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Den 27 Sep 2005 09:54:08 GMT skrev Hans Joergensen:
>>Hvad koster en kasse med 10 hotplug-harddiske (nok til 10 ugentlige
>>backups)?
>
> Vi snakker 160 GB. Vi ved ikke helt, hvad det er, så vi må antage,
> at vi snakker 160 GB ukomprimerbart.
>
> 200 GB One-Touch + 9 x 200 GB diske = 6.931 kr.
One-Touch? Sådan en USB-ting?
>>Hvad koster en æske med 10 bånd?
>
> LTO2-drev + SCSI-fjæs + 10 x LTO2-bånd = 18.755 kr.
Holy crap, koster bånd-backup i nutidens størrelser så meget - ja så
kan jeg godt se fidusen.
Jeg gav vist 400 kr i sin tid for en æske med 10 bånd (båndstationen
sad i en maskine jeg fik foræret), og nåede kun at bruge et par af
båndene før 4 GB (komprimeret) var for lidt. Harddiske har da i det
mindste den fordel at man normalt køber dem en ad gangen, så man kan
købe en større næste gang - og har man brug for mere plads i maskinen,
køber man bare en større disk, tager backup på den, og bytter dem om,
så den store kommer i maskinen, og den gamle bliver til backup'en.
Siden 4GB blev for lidt har jeg nu også selv brugt harddiske, men det
er mere fordi at jeg efterhånden har en del harddiske liggende jeg
alligevel ikke bruger til andet. Det ender nok med at jeg må have fat
i en USB-ting også, det mest besværlige ved at tage backup (og årsagen
til at jeg ikke gør det helt så tit som jeg burde) er at man skal huske
at sætte skuffen i inden man tænder.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (27-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 27-09-05 17:06 |
|
Kent Friis <nospam@nospam.invalid> writes:
>Holy crap, koster bånd-backup i nutidens størrelser så meget - ja så
>kan jeg godt se fidusen.
En DAT-streamer kan fås ned til 3.500 kr, men så skal du skifte
bånd for hver 12 GB. Båndene er billige - 70 bånd à 45 kr for at
lave 10*160 GB backup.
Fordel: du kan lave bånd-backupløsningen for under 8.000 kroner.
Ulempe: det vil "kun" tage dig en hel weekend at lave en backup,
hvis du hele tiden sidder klar med nye bånd at fodre den med.
(@)
Et LTO2-drev koster 14.500 kr. Det tager en komplet backup af de
160 GB på 200 GB-bånd i løbet af 4-5 timer. Båndene koster 375
kr stykket, men du kan slippe med at købe 10 af dem.
Fordel: Din backup er færdig, før den er forældet. Ingen båndskift.
Ulempe: Du har lige brugt næsten 19.000 kr.
Mvh.
Klaus.
| |
Hans Joergensen (27-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 27-09-05 19:19 |
|
Kent Friis wrote:
> Hvad koster en kasse med 10 hotplug-harddiske (nok til 10 ugentlige
> backups)?
Har du hørt om incremental?
Mit personlige gæt er at rsync med --backup-dir option normalt vil
tillade undo-data flere måneder tilbage for langt hovedparten af
forbrugere, blot man har en 50-100gig man kan putte det på.
> Hvad koster en æske med 10 bånd?
Hvad koster båndaben der skal skifte båndet hver dag?
// Hans
--
Photogallery @ http://nathue.dk
| |
Kent Friis (27-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-05 19:43 |
|
Den 27 Sep 2005 18:18:38 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Hvad koster en kasse med 10 hotplug-harddiske (nok til 10 ugentlige
>> backups)?
>
> Har du hørt om incremental?
Ja, det var det man brugte dengang man lavede backup på disketter.
Men så gik det op for en hvor lang tid det tager at finde den
nyeste udgave af den fil man er kommet til at slette, når man ikke lige
kan huske hvornår man sidst har ændret den, og dermed hvilken disk
den ligger på.
> Mit personlige gæt er at rsync med --backup-dir option normalt vil
> tillade undo-data flere måneder tilbage for langt hovedparten af
> forbrugere, blot man har en 50-100gig man kan putte det på.
>
>> Hvad koster en æske med 10 bånd?
>
> Hvad koster båndaben der skal skifte båndet hver dag?
Mindre i lommepenge end når han skal vaske op :-þ
Og jeg tror ikke du får det billigere end for at skifte harddisk.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (27-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 27-09-05 20:36 |
|
Kent Friis wrote:
>> Har du hørt om incremental?
> Ja, det var det man brugte dengang man lavede backup på disketter.
> Men så gik det op for en hvor lang tid det tager at finde den
> nyeste udgave af den fil man er kommet til at slette, når man ikke lige
> kan huske hvornår man sidst har ændret den, og dermed hvilken disk
> den ligger på.
Og på hvilken måde er det et problem med harddiske?
>> Mit personlige gæt er at rsync med --backup-dir option normalt vil
>> tillade undo-data flere måneder tilbage for langt hovedparten af
>> forbrugere, blot man har en 50-100gig man kan putte det på.
>>> Hvad koster en æske med 10 bånd?
>> Hvad koster båndaben der skal skifte båndet hver dag?
> Mindre i lommepenge end når han skal vaske op :-þ
> Og jeg tror ikke du får det billigere end for at skifte harddisk.
Hvem har sagt at disken skal skiftes?
// Hans
--
http://rd350.nathue.dk - Breaking the ozone-layer since 1985
| |
Thorbjoern Ravn Ande~ (27-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 27-09-05 21:04 |
|
Hans Joergensen <haj@enterprise-server.dk> writes:
> Hvem har sagt at disken skal skiftes?
Typisk plejer man at være glad for at gemme data off-site i tilfælde
af brand/tyveri/meteornedslag.
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (27-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 27-09-05 21:21 |
|
Thorbjoern Ravn Andersen wrote:
>> Hvem har sagt at disken skal skiftes?
> Typisk plejer man at være glad for at gemme data off-site i tilfælde
> af brand/tyveri/meteornedslag.
Typisk vil den datamængde der skal backes op ikke være større end
det kan uploades over natten på en ADSL.
// Hans
--
Red-line-shift,Red-line-shift,etc.etc.Red-Light-Stop,Repeat...
| |
Kent Friis (27-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-05 21:16 |
|
Den 27 Sep 2005 19:36:24 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>>> Har du hørt om incremental?
>> Ja, det var det man brugte dengang man lavede backup på disketter.
>> Men så gik det op for en hvor lang tid det tager at finde den
>> nyeste udgave af den fil man er kommet til at slette, når man ikke lige
>> kan huske hvornår man sidst har ændret den, og dermed hvilken disk
>> den ligger på.
>
> Og på hvilken måde er det et problem med harddiske?
For mig tager det længere tid at sætte backup-harddisken i maskinen,
end det gør at sætte en diskette i.
>>> Mit personlige gæt er at rsync med --backup-dir option normalt vil
>>> tillade undo-data flere måneder tilbage for langt hovedparten af
>>> forbrugere, blot man har en 50-100gig man kan putte det på.
>>>> Hvad koster en æske med 10 bånd?
>>> Hvad koster båndaben der skal skifte båndet hver dag?
>> Mindre i lommepenge end når han skal vaske op :-þ
>> Og jeg tror ikke du får det billigere end for at skifte harddisk.
>
> Hvem har sagt at disken skal skiftes?
En 200 GB harddisk bliver fyldt lige så hurtigt som et 200 GB
bånd.
Og som andre allerede har skrevet, offsite backup.
Og så er der jo lige den med at sålænge harddisken er tilsluttet kan
man komme til at slette den ved et uheld. Typisk den slags uheld
hvor man netop har brug for at restore backup'en bagefter.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (27-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 27-09-05 21:25 |
|
Kent Friis wrote:
>> Hvem har sagt at disken skal skiftes?
> En 200 GB harddisk bliver fyldt lige så hurtigt som et 200 GB
> bånd.
Men hvor længe har du behov for at gemme backup bagud i tiden?
Jeg arbejder i en 3D-virksomhed med i gennemsnit 8 3D-animatorer, og
den datamængde der ryger i backup-dir med rsync er gennemsnitligt
ca. 2gig om dagen, ikke specielt voldsomt når man tænker på at
filserveren er 1.3TB stor pt, vi har en tilsvarende filserver
stående offsite til backup, dog med en sjat mere plads.
> Og så er der jo lige den med at sålænge harddisken er tilsluttet kan
> man komme til at slette den ved et uheld. Typisk den slags uheld
> hvor man netop har brug for at restore backup'en bagefter.
Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
hvis den slags uheld sker bør man begrænse sin rootadgang noget
bedre.
// Hans
--
Photogallery @ http://nathue.dk
| |
Thorbjoern Ravn Ande~ (28-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 28-09-05 01:20 |
|
Hans Joergensen <haj@enterprise-server.dk> writes:
> Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
> hvis den slags uheld sker bør man begrænse sin rootadgang noget
> bedre.
Uheld kan altid ske.
Det er set før at harddiske dør fx, eller at man skriver forkert.
Af samme grund bør genetablering scriptes og det bør laves hyppige
brandøvelser så risikonen for det går galt når det virkelig spidser
til kl 3 om natten er mindst mulig.
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (28-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 28-09-05 03:21 |
|
Thorbjoern Ravn Andersen wrote:
>> Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
>> hvis den slags uheld sker bør man begrænse sin rootadgang noget
>> bedre.
> Uheld kan altid ske.
Hvis man er så klodset at man sletter en backup-harddisk tror jeg
ikke man kan finde ud at at håndtere en bånd-backup uden robot.
Jeg vil til en hver tid foretrække backup til disk så længe det er
små datamængder, og hvis en "fornuftig" tape-løsning koster 18000,- er
det nok en lille smule billigere at købe et par af Maxtor's Shared
Storage 300gig diske, placere dem fornuftigt langt fra serveren og
gemt lidt væk, og synce til dem hver nat med incremential til
slettede/ændrede filer.
Med typisk lille-kontor brug vil 300gig formodentligt være nok til
incremential backup ca. 40 år tilbage i tiden.
Bånd kræver manuelt arbejde, og den slags virker bare ikke med et
backup-system.. og hvad når en får slettet den famøse fil, så skal
lige en tur offsite for at hente båndet, båndstationen skal søge
rundt efter filen (og det er altid lige præcis dér at index er gået
i stykker)..
Med harddisk-backup kan man restore filen på et øjeblik, og man behøver
ikke rejse sig fra sin stol.
> Det er set før at harddiske dør fx, eller at man skriver forkert.
Og af en eller anden årsag går alle andre end mig i den her tråd ud
fra at bånd ikke kan gå i stykker..
bånd der måske bliver transporteret offsite hver dag, og fx. bliver
efterladt i en bil i solen fordi man lige skal købe 2 liter mælk.
Vi antager også at båndstationen ikke kan gå i stykker, og at man
når den alligevel gør det sagtens kan købe en tilsvarende
båndstation der rent faktisk er i stand til at læse de gamle bånd
uden problemer.
Samtidlig bliver det antaget at bånd har evigt liv og aldrig bliver
slidt op.
> Af samme grund bør genetablering scriptes og det bør laves hyppige
> brandøvelser så risikonen for det går galt når det virkelig spidser
> til kl 3 om natten er mindst mulig.
Man bør ihvertfald verificere at der er de ting på backuppen der bør
være.
// Hans
--
http://rd350.nathue.dk - Breaking the ozone-layer since 1985
| |
Kent Friis (28-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-05 15:58 |
|
Den 28 Sep 2005 02:20:37 GMT skrev Hans Joergensen:
> Thorbjoern Ravn Andersen wrote:
>>> Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
>>> hvis den slags uheld sker bør man begrænse sin rootadgang noget
>>> bedre.
>> Uheld kan altid ske.
>
> Hvis man er så klodset at man sletter en backup-harddisk tror jeg
> ikke man kan finde ud at at håndtere en bånd-backup uden robot.
Den store hemmelighed er at man skal fysisk sætte båndet i maskinen
før en tastefejl kan ødelægge backup'en. Hverken cron, tastefejl
i fdisk eller lignende kan slette et off-site backupbånd.
> Bånd kræver manuelt arbejde, og den slags virker bare ikke med et
> backup-system..
Hvad koster en harddisk-robot?
> og hvad når en får slettet den famøse fil, så skal
> lige en tur offsite for at hente båndet, båndstationen skal søge
> rundt efter filen (og det er altid lige præcis dér at index er gået
> i stykker)..
Off-site backups er lige vigtige uanset om det er en harddisk eller
et bånd. Påstår du at det er hurtigere at hente en harddisk?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 06:12 |
|
Kent Friis wrote:
> Den store hemmelighed er at man skal fysisk sætte båndet i maskinen
> før en tastefejl kan ødelægge backup'en. Hverken cron, tastefejl
> i fdisk eller lignende kan slette et off-site backupbånd.
fdisk ødelægger ikke noget.
>> Bånd kræver manuelt arbejde, og den slags virker bare ikke med et
>> backup-system..
> Hvad koster en harddisk-robot?
Er en harddiskrobot nødvendig?
> Off-site backups er lige vigtige uanset om det er en harddisk eller
> et bånd. Påstår du at det er hurtigere at hente en harddisk?
Nej, men en harddisk giver flere muligheder.. fx. kan den være
monteret i en computer der sidder på en ADSL i den anden ende af
byen. Og ja, så er det ganske meget hurtigere at hente et par filer
fra en harddisk.
// Hans
--
http://www.dkfritidmotorcykel.dk/Hans_Joergensen
| |
Thorbjoern Ravn Ande~ (29-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 29-09-05 08:07 |
|
Hans Joergensen <haj@enterprise-server.dk> writes:
> Nej, men en harddisk giver flere muligheder.. fx. kan den være
> monteret i en computer der sidder på en ADSL i den anden ende af
> byen. Og ja, så er det ganske meget hurtigere at hente et par filer
> fra en harddisk.
Harddiske har det med at stå af.
Personligt ville jeg nok være fint tilfreds med langtidstapebackup med
Amanda kombineret med en eller flere offsite backup X dage tilbage på
en harddisk langt væk. Amanda er flink til at fortælle hvilke bånd
den gerne vil have for at reetablere et givent sæt filer.
I tidernes morgen lavede jeg et system hvor daglig backup med nok bånd
til at række 3-4 uger tilbage blev kombineret med en månedlig backup
af alle brugere på et nyt bånd hver gang. Det var på en
uddannelsesinstitution så der var en forholdsvis stor gennemstrømning
af brugere, og det er dejligt rart at man blot kan zappe inaktive
brugere og vide at deres hjemmekatalog ligger i en del kopier i
båndarkivet.
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 08:04 |
|
Thorbjoern Ravn Andersen wrote:
>> Nej, men en harddisk giver flere muligheder.. fx. kan den være
>> monteret i en computer der sidder på en ADSL i den anden ende af
>> byen. Og ja, så er det ganske meget hurtigere at hente et par filer
>> fra en harddisk.
> Harddiske har det med at stå af.
Og det har bånd ikke?
Køb mere end en disk.
// Hans
--
Gumminumser == Champignons
| |
Thorbjoern Ravn Ande~ (29-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 29-09-05 10:36 |
|
Hans Joergensen <haj@enterprise-server.dk> writes:
> > Harddiske har det med at stå af.
>
> Og det har bånd ikke?
Joda. Derfor redundansen.
> Køb mere end en disk.
Brug mere end en backupmetode.
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 11:03 |
|
Thorbjoern Ravn Andersen wrote:
>> Og det har bånd ikke?
> Joda. Derfor redundansen.
>> Køb mere end en disk.
> Brug mere end en backupmetode.
Det kan også blive overkill 
// Hans
--
http://ph33r.dk - Helt galt .. :)
| |
Thorbjoern Ravn Ande~ (29-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 29-09-05 11:14 |
|
Hans Joergensen <haj@enterprise-server.dk> writes:
> >> Køb mere end en disk.
> > Brug mere end en backupmetode.
>
> Det kan også blive overkill
Det afhænger jo af hvor vigtige dine data er.
Jeg har arbejdet et sted hvor der blev genereret mindst 100 Mb nye
data hver dag (det er 10 år siden så det betød faktisk noget) som
principielt skulle være tilgængelige til evig tid, og som firmaet
levede af. I sådant et tilfælde ville et redundant backupsystem være
ret relevant.
Men det er jo en individuel vurdering.
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 12:03 |
|
Thorbjoern Ravn Andersen wrote:
> Men det er jo en individuel vurdering.
Det er jo det det er.. her kører både produktions og backup-system
RAID5 (desværre er der blevet indkøbt diskkasser der har så dårlig
I/O at det i praksis ikke kan svare sig at køre RAID1+0 for at få
bedre ydelse:o/) og jeg vil mene risikoen for at begge systemer
brydre ned samtidlig er ganske lille. Specielt da backuppen er
placeret i en anden bygning.
// Hans
--
The Computer Festival of The Year | http://scene-event.dk
| |
Thorbjoern Ravn Ande~ (29-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 29-09-05 13:02 |
|
Hans Joergensen <haj@enterprise-server.dk> writes:
> I/O at det i praksis ikke kan svare sig at køre RAID1+0 for at få
> bedre ydelse:o/) og jeg vil mene risikoen for at begge systemer
> brydre ned samtidlig er ganske lille. Specielt da backuppen er
> placeret i en anden bygning.
Der er ingen fare for at tyveknægte løber med det hele?
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 12:58 |
|
Thorbjoern Ravn Andersen wrote:
>> I/O at det i praksis ikke kan svare sig at køre RAID1+0 for at få
>> bedre ydelse:o/) og jeg vil mene risikoen for at begge systemer
>> brydre ned samtidlig er ganske lille. Specielt da backuppen er
>> placeret i en anden bygning.
> Der er ingen fare for at tyveknægte løber med det hele?
Jowda, hvis de bryder ind i to bygninger der begge er udstyret med
alarmsystem og stjæler præcist disse rackmonterede kasser istedet
for noget af alt det andet dyre grej :)
// Hans
--
http://www.dkfritidmotorcykel.dk/Hans_Joergensen
| |
Kent Friis (29-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-05 15:36 |
|
Den 29 Sep 2005 05:11:38 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Den store hemmelighed er at man skal fysisk sætte båndet i maskinen
>> før en tastefejl kan ødelægge backup'en. Hverken cron, tastefejl
>> i fdisk eller lignende kan slette et off-site backupbånd.
>
> fdisk ødelægger ikke noget.
Det er muligt, men det er f*ndens svært at genoprette de rigtige
partitioner bagefter, når man opdager at det er den forkerte disk
man har ompartitioneret.
>>> Bånd kræver manuelt arbejde, og den slags virker bare ikke med et
>>> backup-system..
>> Hvad koster en harddisk-robot?
>
> Er en harddiskrobot nødvendig?
Det var ikke mig der påstod at en båndrobot er nødvendig. Kravene for
at opnå samme niveau af sikkerhed må være de samme uanset om man bruger
bånd eller harddisk.
>> Off-site backups er lige vigtige uanset om det er en harddisk eller
>> et bånd. Påstår du at det er hurtigere at hente en harddisk?
>
> Nej, men en harddisk giver flere muligheder.. fx. kan den være
> monteret i en computer der sidder på en ADSL i den anden ende af
> byen. Og ja, så er det ganske meget hurtigere at hente et par filer
> fra en harddisk.
Hvordan er det anderledes end et bånd (hvis vi lige ser bort fra den
sekventielle tilgang)?
Jo nemmere det er at få adgang til backup'en, jo nemmere er det at
overskrive/slette den ved et uheld.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 19:02 |
|
Kent Friis wrote:
>> fdisk ødelægger ikke noget.
> Det er muligt, men det er f*ndens svært at genoprette de rigtige
> partitioner bagefter, når man opdager at det er den forkerte disk
> man har ompartitioneret.
Nej det er ikke, med mindre man også har kørt mkfs.
>> Er en harddiskrobot nødvendig?
> Det var ikke mig der påstod at en båndrobot er nødvendig. Kravene for
> at opnå samme niveau af sikkerhed må være de samme uanset om man bruger
> bånd eller harddisk.
Sludder, bånd kræver manuelt arbejde, harddiske kræver ikke specielt
meget manuelt arbejde.
>> Nej, men en harddisk giver flere muligheder.. fx. kan den være
>> monteret i en computer der sidder på en ADSL i den anden ende af
>> byen. Og ja, så er det ganske meget hurtigere at hente et par filer
>> fra en harddisk.
> Hvordan er det anderledes end et bånd (hvis vi lige ser bort fra den
> sekventielle tilgang)?
Det kan ske per automatik, hvis du ikke har en robot er man tvunget
til at tage backuppen offsite manuelt..
Hvem gør det når den normale mand er syg? hvem gør det i
feriesituationer? bliver båndet opbevaret fornuftigt under
transporten?
> Jo nemmere det er at få adgang til backup'en, jo nemmere er det at
> overskrive/slette den ved et uheld.
Ja, og jo nemmere er det at restore den fil man lige står og mangler
og som skal bruges NU NU NU NU!
// Hans
--
Hi! I'm a .signature virus!
Copy me into your ~/.signature to help me spread!
| |
Kent Friis (29-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-05 21:21 |
|
Den 29 Sep 2005 18:01:33 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>>> Er en harddiskrobot nødvendig?
>> Det var ikke mig der påstod at en båndrobot er nødvendig. Kravene for
>> at opnå samme niveau af sikkerhed må være de samme uanset om man bruger
>> bånd eller harddisk.
>
> Sludder, bånd kræver manuelt arbejde, harddiske kræver ikke specielt
> meget manuelt arbejde.
Hvilket manuelt arbejde kræver et bånd, som en harddisk på samme
størrelse ikke gør, for at opnå samme niveau af sikkerhed?
>>> Nej, men en harddisk giver flere muligheder.. fx. kan den være
>>> monteret i en computer der sidder på en ADSL i den anden ende af
>>> byen. Og ja, så er det ganske meget hurtigere at hente et par filer
>>> fra en harddisk.
>> Hvordan er det anderledes end et bånd (hvis vi lige ser bort fra den
>> sekventielle tilgang)?
>
> Det kan ske per automatik, hvis du ikke har en robot er man tvunget
> til at tage backuppen offsite manuelt..
Førnævnte harddisk-robot? Eller mener du at harddisken selv flyver?
> Hvem gør det når den normale mand er syg? hvem gør det i
> feriesituationer? bliver båndet opbevaret fornuftigt under
> transporten?
Stadig samme problem uanset om det er bånd eller harddisk.
>> Jo nemmere det er at få adgang til backup'en, jo nemmere er det at
>> overskrive/slette den ved et uheld.
>
> Ja, og jo nemmere er det at restore den fil man lige står og mangler
> og som skal bruges NU NU NU NU!
Nej, det er meget sværere at restore en fil når man er kommet til at
slette backup'en sammen med resten af systemet.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (30-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 30-09-05 00:44 |
|
Kent Friis wrote:
>> Det kan ske per automatik, hvis du ikke har en robot er man tvunget
>> til at tage backuppen offsite manuelt..
> Førnævnte harddisk-robot? Eller mener du at harddisken selv flyver?
offsite er ikke det samme som offline.
// Hans
--
Gumminumser == Champignons
| |
Kent Friis (28-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-05 15:54 |
|
Den 27 Sep 2005 20:25:12 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>>> Hvem har sagt at disken skal skiftes?
>> En 200 GB harddisk bliver fyldt lige så hurtigt som et 200 GB
>> bånd.
>
> Men hvor længe har du behov for at gemme backup bagud i tiden?
Lige så længe som man kan konstatere "s*t*ns også, den fil skulle
jeg alligevel ikke have slettet".
> Jeg arbejder i en 3D-virksomhed med i gennemsnit 8 3D-animatorer, og
> den datamængde der ryger i backup-dir med rsync er gennemsnitligt
> ca. 2gig om dagen, ikke specielt voldsomt når man tænker på at
> filserveren er 1.3TB stor pt, vi har en tilsvarende filserver
> stående offsite til backup, dog med en sjat mere plads.
Det kræver en eller anden form for revisions-kontrol hvis man skal
have flere generationer af backups på samme medie, uden at skulle
til at søge hver backup igennem for sig for at finde nyeste udgave
af en fil. Har man ikke det, må man nøjes med at tage komplette
backups.
>> Og så er der jo lige den med at sålænge harddisken er tilsluttet kan
>> man komme til at slette den ved et uheld. Typisk den slags uheld
>> hvor man netop har brug for at restore backup'en bagefter.
>
> Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
> hvis den slags uheld sker bør man begrænse sin rootadgang noget
> bedre.
Den slags uheld er netop årsagen til at man har brug for backup.
Jeg fandt selv ud af hvor vigtig backup er da jeg kom til at køre
fdisk på hda (den med data) i stedet for hdb (den nye).
På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
sad i maskinen, som lige præcis var dem der indeholdt den backup fra
aftenen i forvejen som vi havde brug for at restore. Fra den dag
satte vi backupscriptet til at ejecte båndene automatisk så snart
backup'en var færdig.
Så jo, det sker.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjoern Ravn Ande~ (28-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 28-09-05 18:30 |
|
Kent Friis <nospam@nospam.invalid> writes:
> På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
> gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
> sad i maskinen, som lige præcis var dem der indeholdt den backup fra
> aftenen i forvejen som vi havde brug for at restore. Fra den dag
> satte vi backupscriptet til at ejecte båndene automatisk så snart
> backup'en var færdig.
Amanda!
--
Thorbjørn Ravn Andersen
| |
Kent Friis (28-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-05 18:45 |
|
Den 28 Sep 2005 19:30:11 +0200 skrev Thorbjoern Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
>> gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
>> sad i maskinen, som lige præcis var dem der indeholdt den backup fra
>> aftenen i forvejen som vi havde brug for at restore. Fra den dag
>> satte vi backupscriptet til at ejecte båndene automatisk så snart
>> backup'en var færdig.
>
> Amanda!
Kan den se forskel på det bånd der skal overskrives og det der ikke må?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (28-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-05 19:12 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Amanda!
>Kan den se forskel på det bånd der skal overskrives og det der ikke må?
Ja, der er en label i starten af båndet, som Amanda kontrollerer.
Den nægter at skrive på et forkert bånd.
Mvh.
Klaus.
| |
Tommy Eriksen (28-09-2005)
| Kommentar
Fra : Tommy Eriksen |
Dato : 28-09-05 19:18 |
|
On 28 Sep 2005 17:45:29 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>Den 28 Sep 2005 19:30:11 +0200 skrev Thorbjoern Ravn Andersen:
>> Kent Friis <nospam@nospam.invalid> writes:
>>
>>> På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
>>> gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
>>> sad i maskinen, som lige præcis var dem der indeholdt den backup fra
>>> aftenen i forvejen som vi havde brug for at restore. Fra den dag
>>> satte vi backupscriptet til at ejecte båndene automatisk så snart
>>> backup'en var færdig.
>>
>> Amanda!
>
>Kan den se forskel på det bånd der skal overskrives og det der ikke må?
Umiddelbart (hvis jeg ikke husker helt fejl - vi bruger Amanda til
backup til harddisk, ikke bånd) så kan den, ja. Den holder i hvert
fald en liste af dine bånd og beder selv om det den skal bruge til
næste backup, jeg mener absolut den checker headeren på båndet og
nægter at overskrive det hvis den ikke selv mener, at det er modent
til genbrug. Så går backuppen til dens holding disk(e) midlertidigt og
kan så flushes til bånd når man får sat det rigtige i.
Vi har i øvrigt brugt det i i hvert fald 4 år, og har altid været
ovenud tilfredse. I øjeblikket til backup af omkring 130 filsystemer,
med ca 2.5TB backupstorage, uden problemer af nogen art.
Kopiering til offsite storage klares så iøvrigt stille og roligt med
en rsync efter nattens backup.
/Tommy
| |
Kent Friis (28-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-05 20:12 |
|
Den Wed, 28 Sep 2005 20:18:11 +0200 skrev Tommy Eriksen:
> On 28 Sep 2005 17:45:29 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Den 28 Sep 2005 19:30:11 +0200 skrev Thorbjoern Ravn Andersen:
>>> Kent Friis <nospam@nospam.invalid> writes:
>>>
>>>> På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
>>>> gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
>>>> sad i maskinen, som lige præcis var dem der indeholdt den backup fra
>>>> aftenen i forvejen som vi havde brug for at restore. Fra den dag
>>>> satte vi backupscriptet til at ejecte båndene automatisk så snart
>>>> backup'en var færdig.
>>>
>>> Amanda!
>>
>>Kan den se forskel på det bånd der skal overskrives og det der ikke må?
>
> Umiddelbart (hvis jeg ikke husker helt fejl - vi bruger Amanda til
> backup til harddisk, ikke bånd) så kan den, ja. Den holder i hvert
> fald en liste af dine bånd og beder selv om det den skal bruge til
> næste backup, jeg mener absolut den checker headeren på båndet og
> nægter at overskrive det hvis den ikke selv mener, at det er modent
> til genbrug.
Det skal den jo så ikke bestemme (er der noget værre end software der
forsøger at bestemme?).
Men som jeg læser svaret, løser det kun problemet for bånd, hvor
problemet allerede er løst (ved at ejecte båndet). Det var harddiske
der blev anbefalet, og jeg har endnu ikke set en løsning der kan
ejecte harddiske fra software.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjoern Ravn Ande~ (28-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 28-09-05 19:53 |
|
Kent Friis <nospam@nospam.invalid> writes:
> > Amanda!
>
> Kan den se forskel på det bånd der skal overskrives og det der ikke må?
Ja.
Den ved hvilket den vil have og den nægter at overskrive førend den
får det (så laver den bare globalt inkrementalt dump til buffer
istedet - det spooler man så ud når det virker igen).
--
Thorbjørn Ravn Andersen
| |
Sune Vuorela (28-09-2005)
| Kommentar
Fra : Sune Vuorela |
Dato : 28-09-05 21:29 |
|
On 2005-09-28, Thorbjoern Ravn Andersen <nospam0000@gmail.com> wrote:
> Den ved hvilket den vil have og den nægter at overskrive førend den
> får det (så laver den bare globalt inkrementalt dump til buffer
Kan man godt fortælle den "Ja! jeg vil skrive på dette bånd selvom du
vil have et andet" ?
--
Sune
| |
Klaus Ellegaard (28-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-05 21:32 |
|
Sune Vuorela <nospam@vuorela.dk> writes:
>Kan man godt fortælle den "Ja! jeg vil skrive på dette bånd selvom du
>vil have et andet" ?
Nej, men du kan bede den om at lave en ny label på båndet, så det
kommer til at stå som et andet bånd. Det er dog ikke noget, man
"kommer til" at gøre.
Mvh.
Klaus.
| |
Sune Vuorela (28-09-2005)
| Kommentar
Fra : Sune Vuorela |
Dato : 28-09-05 21:43 |
|
On 2005-09-28, Klaus Ellegaard <klausellegaard@msn.com> wrote:
> Nej, men du kan bede den om at lave en ny label på båndet, så det
> kommer til at stå som et andet bånd. Det er dog ikke noget, man
> "kommer til" at gøre.
Fint - bare så længe at det er muligt når man ved hvad man gør.
--
Sune
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 06:05 |
|
Kent Friis wrote:
> Lige så længe som man kan konstatere "s*t*ns også, den fil skulle
> jeg alligevel ikke have slettet".
Man sletter vel ikke noget med mindre man er _RIMELIGT_ sikker på at
det aldrig skal bruges mere.
> Det kræver en eller anden form for revisions-kontrol hvis man skal
> have flere generationer af backups på samme medie, uden at skulle
> til at søge hver backup igennem for sig for at finde nyeste udgave
> af en fil. Har man ikke det, må man nøjes med at tage komplette
> backups.
rsync -av --exclude-from /etc/exclude --delete --backup
--backup-dir=/backup/inch/`date +%Y%m%d` / backupserver:/backup/full
ssh backupserver
find /backup -name "denfilmanmangler"
Så får man den komplet med dato og hele pivetøjet, det er udemærket.
Evt. kan man sætte rsync til at hardlinke, så får man hele
snapshots.
Såfremt en backupserver er en tand for dyrt kan man kigge på
http://openmss.org, en fin lille backupserver man fint kan gemme et
hvilketsomhelst sted man kan trække et netkabel til :)
>> Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
>> hvis den slags uheld sker bør man begrænse sin rootadgang noget
>> bedre.
> Den slags uheld er netop årsagen til at man har brug for backup.
> Jeg fandt selv ud af hvor vigtig backup er da jeg kom til at køre
> fdisk på hda (den med data) i stedet for hdb (den nye).
Havde det så ikke været nemmere at genskabe partitionerne med gpart
frem for at hive backuppen frem?
> På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
> gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
> sad i maskinen, som lige præcis var dem der indeholdt den backup fra
> aftenen i forvejen som vi havde brug for at restore. Fra den dag
> satte vi backupscriptet til at ejecte båndene automatisk så snart
> backup'en var færdig.
På samme måde er der vel heller ikke noget galt for at umount'e en
backupdisk når jobbet er færdigt.
Den option bruger jeg ikke, men jeg er også den eneste (ok, reelt er
vi to) der har adgang til backup-serveren, og jeg anser det ikke for
sansynligt at jeg kommer til at slette hele backuppen.
// Hans
--
The Computer Festival of The Year | http://scene-event.dk
| |
Kent Friis (29-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-05 15:31 |
|
Den 29 Sep 2005 05:04:58 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Lige så længe som man kan konstatere "s*t*ns også, den fil skulle
>> jeg alligevel ikke have slettet".
>
> Man sletter vel ikke noget med mindre man er _RIMELIGT_ sikker på at
> det aldrig skal bruges mere.
Hvis man tror på den, har man slet ikke brug for backup.
>> Det kræver en eller anden form for revisions-kontrol hvis man skal
>> have flere generationer af backups på samme medie, uden at skulle
>> til at søge hver backup igennem for sig for at finde nyeste udgave
>> af en fil. Har man ikke det, må man nøjes med at tage komplette
>> backups.
>
> rsync -av --exclude-from /etc/exclude --delete --backup
> --backup-dir=/backup/inch/`date +%Y%m%d` / backupserver:/backup/full
Den ser ud til at have præcis samme problem som cronjobbet der
overskrev backup'en, fordi datoen på maskinen var forkert.
> ssh backupserver
> find /backup -name "denfilmanmangler"
> Så får man den komplet med dato og hele pivetøjet, det er udemærket.
Jeg har lidt svært ved at se hvordan du vil få den offsite, og sikre
at den ikke efterfølgende bliver overskrevet/slettet når man laver
den fejl der netop er årsagen til at man har brug for at restore
backup'en.
>> Den slags uheld er netop årsagen til at man har brug for backup.
>> Jeg fandt selv ud af hvor vigtig backup er da jeg kom til at køre
>> fdisk på hda (den med data) i stedet for hdb (den nye).
>
> Havde det så ikke været nemmere at genskabe partitionerne med gpart
> frem for at hive backuppen frem?
1. Jeg tror ikke gpart eksisterede på det tidspunkt.
2. Jeg havde ikke hørt om den.
3. Jeg havde ingen internet-forbindelse - og havde jeg haft det, plejer
den heller ikke at være brugbar uden et OS.
4. Jeg havde heller ingen backup - men jeg lærte noget.
>> På arbejdet havde vi engang et uheld med cron, der gjorde at backup'en
>> gik igang på et forkert tidspunkt, og overskrev de bånd der stadig
>> sad i maskinen, som lige præcis var dem der indeholdt den backup fra
>> aftenen i forvejen som vi havde brug for at restore. Fra den dag
>> satte vi backupscriptet til at ejecte båndene automatisk så snart
>> backup'en var færdig.
>
> På samme måde er der vel heller ikke noget galt for at umount'e en
> backupdisk når jobbet er færdigt.
umount beskytter kun mod filsystem-tilgang. Man skal faktisk helst
umount'e en harddisk inden man går igang med fdisk.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 18:59 |
|
Kent Friis wrote:
>> Man sletter vel ikke noget med mindre man er _RIMELIGT_ sikker på at
>> det aldrig skal bruges mere.
> Hvis man tror på den, har man slet ikke brug for backup.
Jowda, der er jo stadig hardwarefejl, samt dumme brugere og explorer
der uden kvaler sletter filer når en bruger kommer til at trykke på
delete det forkerte sted.
(så ryger de jo heldigvis igennem recycle.so i samba, nemt at hive
frem igen
>>> Det kræver en eller anden form for revisions-kontrol hvis man skal
>>> have flere generationer af backups på samme medie, uden at skulle
>>> til at søge hver backup igennem for sig for at finde nyeste udgave
>>> af en fil. Har man ikke det, må man nøjes med at tage komplette
>>> backups.
>> rsync -av --exclude-from /etc/exclude --delete --backup
>> --backup-dir=/backup/inch/`date +%Y%m%d` / backupserver:/backup/full
> Den ser ud til at have præcis samme problem som cronjobbet der
> overskrev backup'en, fordi datoen på maskinen var forkert.
Hvilket problem er det præcis? Med den her metode er det usansynligt
at noget bliver overskrevet.
I øvrigt er det sjældent at tiden går skævt hvis man bruger ntp.
>> ssh backupserver
>> find /backup -name "denfilmanmangler"
>> Så får man den komplet med dato og hele pivetøjet, det er udemærket.
> Jeg har lidt svært ved at se hvordan du vil få den offsite, og sikre
> at den ikke efterfølgende bliver overskrevet/slettet når man laver
> den fejl der netop er årsagen til at man har brug for at restore
> backup'en.
Ingen siger at backup-serveren behøver stå på samme site, den kan i
teorien stå i Indokina.
> umount beskytter kun mod filsystem-tilgang. Man skal faktisk helst
> umount'e en harddisk inden man går igang med fdisk.
Betyder intet, man skal bare genstarte før det er aktivt
// Hans
--
http://www.dkfritidmotorcykel.dk/?id=43
| |
Kent Friis (29-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-05 21:16 |
|
Den 29 Sep 2005 17:58:56 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>>> Man sletter vel ikke noget med mindre man er _RIMELIGT_ sikker på at
>>> det aldrig skal bruges mere.
>> Hvis man tror på den, har man slet ikke brug for backup.
>
> Jowda, der er jo stadig hardwarefejl, samt dumme brugere og explorer
> der uden kvaler sletter filer når en bruger kommer til at trykke på
> delete det forkerte sted.
Du bliver klogere...
>>>> Det kræver en eller anden form for revisions-kontrol hvis man skal
>>>> have flere generationer af backups på samme medie, uden at skulle
>>>> til at søge hver backup igennem for sig for at finde nyeste udgave
>>>> af en fil. Har man ikke det, må man nøjes med at tage komplette
>>>> backups.
>>> rsync -av --exclude-from /etc/exclude --delete --backup
>>> --backup-dir=/backup/inch/`date +%Y%m%d` / backupserver:/backup/full
>> Den ser ud til at have præcis samme problem som cronjobbet der
>> overskrev backup'en, fordi datoen på maskinen var forkert.
>
> Hvilket problem er det præcis? Med den her metode er det usansynligt
> at noget bliver overskrevet.
Når uret pludselig tror det er en helt anden dag end det rent faktisk
er, vil date-kommandoen gøre at den overskriver backup'en fra den
dag uret påstår det er.
>>> ssh backupserver
>>> find /backup -name "denfilmanmangler"
>>> Så får man den komplet med dato og hele pivetøjet, det er udemærket.
>> Jeg har lidt svært ved at se hvordan du vil få den offsite, og sikre
>> at den ikke efterfølgende bliver overskrevet/slettet når man laver
>> den fejl der netop er årsagen til at man har brug for at restore
>> backup'en.
>
> Ingen siger at backup-serveren behøver stå på samme site, den kan i
> teorien stå i Indokina.
Hvis der stadig er adgang til maskinen over netværket, er den ikke
længere væk fra delete tasten end den man har stående på skrivebordet.
Et bånd eller en harddisk der ligger i et låst brandsikkert skab er
umuligt at slette med en tastefejl, uanset hvor grov den er.
>> umount beskytter kun mod filsystem-tilgang. Man skal faktisk helst
>> umount'e en harddisk inden man går igang med fdisk.
>
> Betyder intet, man skal bare genstarte før det er aktivt
Det var ikke det der var problemet.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (30-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 30-09-05 00:42 |
|
Kent Friis wrote:
>> Hvilket problem er det præcis? Med den her metode er det usansynligt
>> at noget bliver overskrevet.
> Når uret pludselig tror det er en helt anden dag end det rent faktisk
> er, vil date-kommandoen gøre at den overskriver backup'en fra den
> dag uret påstår det er.
Den vil allerhøjst overskrive backup af filer der blev ændret den
aktuelle dato med filer der har samme navne der igen er blevet
ændret. Men det kan man i øvrigt scripte sig af.
>> Ingen siger at backup-serveren behøver stå på samme site, den kan i
>> teorien stå i Indokina.
> Hvis der stadig er adgang til maskinen over netværket, er den ikke
> længere væk fra delete tasten end den man har stående på skrivebordet.
Korrekt.. hvis man er en enormt klodset administrator.
// Hans
--
http://rd350.nathue.dk - Breaking the ozone-layer since 1985
| |
Kent Friis (30-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-05 15:06 |
|
Den 29 Sep 2005 23:42:27 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>>> Hvilket problem er det præcis? Med den her metode er det usansynligt
>>> at noget bliver overskrevet.
>> Når uret pludselig tror det er en helt anden dag end det rent faktisk
>> er, vil date-kommandoen gøre at den overskriver backup'en fra den
>> dag uret påstår det er.
>
> Den vil allerhøjst overskrive backup af filer der blev ændret den
> aktuelle dato med filer der har samme navne der igen er blevet
> ændret.
Altså lige præcis dem det ville være kritisk at restore.
>>> Ingen siger at backup-serveren behøver stå på samme site, den kan i
>>> teorien stå i Indokina.
>> Hvis der stadig er adgang til maskinen over netværket, er den ikke
>> længere væk fra delete tasten end den man har stående på skrivebordet.
>
> Korrekt.. hvis man er en enormt klodset administrator.
Eller med andre ord, hvis man har brug for backup.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (30-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 30-09-05 15:21 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Korrekt.. hvis man er en enormt klodset administrator.
>Eller med andre ord, hvis man har brug for backup.
Nu er der jo mange måder at være uheldig på. Der findes ingen
backup-procedure, der er "god nok", for problemer som silent
corruption og database-crash i selve backupsystemet vil altid
kunne ødelægge (eller forsinke recovery med) stort set enhver
fornuftig strategi.
Man kan jo være så klodset at komme til at tabe et bånd ned i
en blender. Man kan også være så uheldig, at bånd eller disk
bliver ramt af et meteor. (Sandsynligheden for sidstnævnte er
nok ca. lige så stor som for at man sletter den forkerte disk).
Og så videre...
Det er i bund og grund et spørgsmål om, hvad der er økonomisk
forsvarligt i forhold til mulighed for recovery, hastigheden
på recovery ift. løbende tab og muligheden for at klare sig
med en ældre backup.
Så det er praktisk talt umuligt at generaliseret at sige, at
"denne backupmetode er for risikabel/dårlig/usikker/farlig".
Mvh.
Klaus.
| |
Kent Friis (30-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-05 16:03 |
|
Den Fri, 30 Sep 2005 14:21:23 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Korrekt.. hvis man er en enormt klodset administrator.
>
>>Eller med andre ord, hvis man har brug for backup.
>
> Nu er der jo mange måder at være uheldig på. Der findes ingen
> backup-procedure, der er "god nok", for problemer som silent
> corruption og database-crash i selve backupsystemet vil altid
> kunne ødelægge (eller forsinke recovery med) stort set enhver
> fornuftig strategi.
Klart, det er jo derfor man har flere generationer af backups (på
separate medier) - det kan ikke løse problemer med silent corruption,
men det er nok det tætteste vi kan komme på.
> Man kan jo være så klodset at komme til at tabe et bånd ned i
> en blender. Man kan også være så uheldig, at bånd eller disk
> bliver ramt af et meteor. (Sandsynligheden for sidstnævnte er
> nok ca. lige så stor som for at man sletter den forkerte disk).
Lever du på månen? Heromkring falder der ikke så mange meteorer ned.
(En disk er ikke ret stor, og hvis der virkelig skulle falde så mange
meteorer ned at sandsynligheden bliver den samme, burde man kunne
finde *mange* flere meteorer i haven (der er mange gange større end
en disk) end det antal gange man er kommet til at slette den
forkerte disk.
> Det er i bund og grund et spørgsmål om, hvad der er økonomisk
> forsvarligt i forhold til mulighed for recovery, hastigheden
> på recovery ift. løbende tab og muligheden for at klare sig
> med en ældre backup.
>
> Så det er praktisk talt umuligt at generaliseret at sige, at
> "denne backupmetode er for risikabel/dårlig/usikker/farlig".
Det er såmænd heller ikke det jeg forsøger at argumentere for, men
derimod at de tekniske "fordele" der er blevet nævnt ved HD-backup
i forhold til bånd-backup ikke er forskelle i mediet, men
forskelle i sikkerheds-niveauet.
Her tænker jeg fx på at harddisken er tilsluttet hele tiden, men
båndet skal skiftes - det er ikke en teknisk forskel, båndet kan
lige så vel blive siddende i båndstationen, eller harddisken kan
lige så vel skulle skiftes, det kommer an på hvilken grad af
sikkerhed man ønsker. Og en 200 GB harddisk bliver fyldt lige så
hurtigt som et 200 GB bånd.
Det eneste reelle argument jeg i denne diskussion har set for HD-backup
er prisen, men det er til gengæld også et godt argument især sålænge
vi snakker om private. Søge-hastigheden kan også være et argument, men
det mener jeg ikke har været fremført.
Derudover har jeg så argumenteret for at hvis man mener "det sker
ikke" om fx at slette en disk ved en fejl, så har man blot ikke
lært det *endnu*. Man har så at sige "men de græder ofte" tilgode.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (30-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 30-09-05 16:14 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Man kan jo være så klodset at komme til at tabe et bånd ned i
>> en blender. Man kan også være så uheldig, at bånd eller disk
>> bliver ramt af et meteor. (Sandsynligheden for sidstnævnte er
>> nok ca. lige så stor som for at man sletter den forkerte disk).
>Lever du på månen? Heromkring falder der ikke så mange meteorer ned.
Næeh, men jeg aldrig hørt om hverken meteornedslag eller diske,
der blev slettet ved et uheld. Derfor antager jeg, at risikoen
i praksis er nogenlunde lige stor 
>Det er såmænd heller ikke det jeg forsøger at argumentere for, men
>derimod at de tekniske "fordele" der er blevet nævnt ved HD-backup
>i forhold til bånd-backup ikke er forskelle i mediet, men
>forskelle i sikkerheds-niveauet.
Det kræver jo en antagelse om, at bånd og harddisk har samme
fysiske kvalitet. Hvis bånd har 1.000 gange større risiko for
at lave ødelæggende båndsalat, end en harddisk har for at lave
et head-crash, taler det samlede billede måske alligevel for
harddisken. Det kan også meget vel være omvendt.
>Derudover har jeg så argumenteret for at hvis man mener "det sker
>ikke" om fx at slette en disk ved en fejl, så har man blot ikke
>lært det *endnu*. Man har så at sige "men de græder ofte" tilgode.
Samme argument med meteoren og båndet. Erstat eventuelt meteoren
med alle de andre ulykker, der kan ramme et bånd. En delmængde af
dem (og nogle ekstra) kan også siges at gælde omkring harddiske.
Der er altså ikke nødvendigvis nogen forskel i risikoen her.
Mvh.
Klaus.
| |
Thorbjoern Ravn Ande~ (30-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 30-09-05 16:45 |
|
Klaus Ellegaard <klausellegaard@msn.com> writes:
> Næeh, men jeg aldrig hørt om hverken meteornedslag eller diske,
> der blev slettet ved et uheld. Derfor antager jeg, at risikoen
> i praksis er nogenlunde lige stor
Det har jeg til gengæld. Et uheldigt mellemrum eller en slåfejl i et
devicenavn hvis man har lidt travlt.
Det er muligt, og det er - efter min erfaring - nemmere for en
Unixadministrator end for en Windows ditto, fordi der er mere visuelt
feedback i Windows.
I gamle dage var det meget nemt at lave overlappende partitioner under
SunOS, så der kunne man også brænde sig når en disk blev fuld.
Og så videre.
> >Derudover har jeg så argumenteret for at hvis man mener "det sker
> >ikke" om fx at slette en disk ved en fejl, så har man blot ikke
> >lært det *endnu*. Man har så at sige "men de græder ofte" tilgode.
>
> Samme argument med meteoren og båndet. Erstat eventuelt meteoren
> med alle de andre ulykker, der kan ramme et bånd. En delmængde af
> dem (og nogle ekstra) kan også siges at gælde omkring harddiske.
>
> Der er altså ikke nødvendigvis nogen forskel i risikoen her.
Er data vigtige nok, er livrem og seler - som tidligere nævnt - ikke
at foragte.
--
Thorbjørn Ravn Andersen
| |
Allan Joergensen (30-09-2005)
| Kommentar
Fra : Allan Joergensen |
Dato : 30-09-05 16:09 |
|
Kent Friis <nospam@nospam.invalid> wrote:
> Derudover har jeg så argumenteret for at hvis man mener "det sker
> ikke" om fx at slette en disk ved en fejl, så har man blot ikke
> lært det *endnu*. Man har så at sige "men de græder ofte" tilgode.
Du har aldrig oplevet at en fil du skulle bruge på mystisk vis var væk
fra din backup fordi din software havde fucket op? Du har aldrig oplevet
at bruge 72 timer på restore fordi backupsoftwaren var nødt til at
scanne alle bånd? Du har aldrig oplevet ikke at kunne restore fordi din
robot ikke har nogle ledige drev? Du har aldrig oplevet at miste hele
din backup historik fordi databasen skred i svinget?
--
Allan Joergensen
"Hmmm. Impressive title..." -Neelix to Janeway
| |
Kent Friis (30-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-05 16:20 |
|
Den 30 Sep 2005 15:09:08 GMT skrev Allan Joergensen:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>> Derudover har jeg så argumenteret for at hvis man mener "det sker
>> ikke" om fx at slette en disk ved en fejl, så har man blot ikke
>> lært det *endnu*. Man har så at sige "men de græder ofte" tilgode.
>
> Du har aldrig oplevet at en fil du skulle bruge på mystisk vis var væk
> fra din backup fordi din software havde fucket op?
Jeg har ikke været ude for at tar har fucket up, nej. Er der større
risiko for at den gør det end at rsync gør det?
> Du har aldrig oplevet
> at bruge 72 timer på restore fordi backupsoftwaren var nødt til at
> scanne alle bånd?
Nej, hvad er det dog for noget underligt software der har brug for
den slags?
> Du har aldrig oplevet ikke at kunne restore fordi din
> robot ikke har nogle ledige drev?
Nej, jeg har ikke brugt hverken bånd-robot eller harddisk-robot.
> Du har aldrig oplevet at miste hele
> din backup historik fordi databasen skred i svinget?
Hvilken database snakker du om?
Og hvordan er det argumenter for at man ikke kommer til at slette
en disk ved et uheld? (Det er det du har quotet, så jeg går ud fra
at det er det du argumenterer imod).
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Allan Joergensen (30-09-2005)
| Kommentar
Fra : Allan Joergensen |
Dato : 30-09-05 19:40 |
|
Kent Friis <nospam@nospam.invalid> wrote:
>> Du har aldrig oplevet
>> at bruge 72 timer på restore fordi backupsoftwaren var nødt til at
>> scanne alle bånd?
> Nej, hvad er det dog for noget underligt software der har brug for
> den slags?
Undskyld, jeg troede bare du var fortaler for RIGTIG båndbackup ikke
noget høkerværk.
>> Du har aldrig oplevet ikke at kunne restore fordi din
>> robot ikke har nogle ledige drev?
> Nej, jeg har ikke brugt hverken bånd-robot eller harddisk-robot.
Og alligevel holder du hårdnakket på at bånd er bedre end (offsite)
diskbackup.
>> Du har aldrig oplevet at miste hele
>> din backup historik fordi databasen skred i svinget?
> Hvilken database snakker du om?
Jeg taler om den database, der indeholder informationer om alle dine
bånd.
> Og hvordan er det argumenter for at man ikke kommer til at slette
> en disk ved et uheld? (Det er det du har quotet, så jeg går ud fra
> at det er det du argumenterer imod).
Din argumentation i mod harddisk backup er firkantet og tilsyneladende
kun baseret på hvordan tingene virker i din egen verden.
Jeg mangler stadig at se det endegyldige argument for hvorfor man skulle
vælge bånd frem for disk til backup, når man taler om så små datamængder
at det kan klares uden en backup robot og/eller en dedikeret backupmand.
Hans (og andre) er kommet med gode argumenter for hvorfor bånd ikke
virker i små installationer, men det skøjter du meget let henover.
(for en god ordens skyld skal det siges at jeg kender både Hans og Klaus
og derfor ved at de rent faktisk har erfaring med det vi snakker om her)
--
Allan Joergensen
"Wow! The Amish are really hauling ass!"
| |
Kent Friis (30-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-05 20:17 |
|
Den 30 Sep 2005 18:40:06 GMT skrev Allan Joergensen:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>>> Du har aldrig oplevet
>>> at bruge 72 timer på restore fordi backupsoftwaren var nødt til at
>>> scanne alle bånd?
>> Nej, hvad er det dog for noget underligt software der har brug for
>> den slags?
>
> Undskyld, jeg troede bare du var fortaler for RIGTIG båndbackup ikke
> noget høkerværk.
"høkerværk"? Er det et skældsord for software der finder på den slags
tåbeligheder?
>>> Du har aldrig oplevet ikke at kunne restore fordi din
>>> robot ikke har nogle ledige drev?
>> Nej, jeg har ikke brugt hverken bånd-robot eller harddisk-robot.
>
> Og alligevel holder du hårdnakket på at bånd er bedre end (offsite)
> diskbackup.
Læste du overhovedet hvad jeg skrev?
>> Og hvordan er det argumenter for at man ikke kommer til at slette
>> en disk ved et uheld? (Det er det du har quotet, så jeg går ud fra
>> at det er det du argumenterer imod).
>
> Din argumentation i mod harddisk backup er firkantet og tilsyneladende
> kun baseret på hvordan tingene virker i din egen verden.
Åbenbart ikke.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (30-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 30-09-05 20:30 |
|
Kent Friis <nospam@nospam.invalid> writes:
[Database over bånd]
>"høkerværk"? Er det et skældsord for software der finder på den slags
>tåbeligheder?
Der findes vist ingen professionelle backupsystemer, der ikke
har en database til at holde styr på indholdet af båndene?
Men omvendt er de også designet til at holde styr på større
mængder data end tråden her oprindeligt handlede om...
Mvh.
Klaus.
| |
Hans Joergensen (02-10-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 02-10-05 08:52 |
|
Kent Friis wrote:
> Jeg har ikke været ude for at tar har fucket up, nej. Er der større
> risiko for at den gør det end at rsync gør det?
rsync fucker aldrig op. tar fucker nu heller aldrig op.
> Nej, hvad er det dog for noget underligt software der har brug for
> den slags?
Legato Networker, Tivoli Storage Manager, og alle mulige andre
"rigtige" backupsystemer
// Hans
--
http://www.dkfritidmotorcykel.dk/?id=43
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 20:32 |
|
Den 02 Oct 2005 07:51:56 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Jeg har ikke været ude for at tar har fucket up, nej. Er der større
>> risiko for at den gør det end at rsync gør det?
>
> rsync fucker aldrig op. tar fucker nu heller aldrig op.
>
>> Nej, hvad er det dog for noget underligt software der har brug for
>> den slags?
>
> Legato Networker, Tivoli Storage Manager, og alle mulige andre
> "rigtige" backupsystemer
Aldrig hørt om dem. Er det sådan noget proprietært skrammel a'la
Windows? :-þ
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 20:37 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Legato Networker, Tivoli Storage Manager, og alle mulige andre
>> "rigtige" backupsystemer
>Aldrig hørt om dem. Er det sådan noget proprietært skrammel a'la
>Windows? :-þ
Det er de løsninger, storforbrugere af backup bruger. De er stort
set umulige at komme udenom, hvis man har data nok til at skulle
bruge robotter.
Det typiske argument for den slags løsninger er, at det ellers er
umuligt at garantere en restoretid. Hvis man har 10 bånd, er det
jo nemt nok. Men har man 100.000 bånd, er det lidt sværere.
Mvh.
Klaus.
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 20:50 |
|
Den Sun, 2 Oct 2005 19:37:16 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Legato Networker, Tivoli Storage Manager, og alle mulige andre
>>> "rigtige" backupsystemer
>
>>Aldrig hørt om dem. Er det sådan noget proprietært skrammel a'la
>>Windows? :-þ
>
> Det er de løsninger, storforbrugere af backup bruger. De er stort
> set umulige at komme udenom, hvis man har data nok til at skulle
> bruge robotter.
Teknisk set svarede du ikke på spørgsmålet.
> Det typiske argument for den slags løsninger er, at det ellers er
> umuligt at garantere en restoretid. Hvis man har 10 bånd, er det
> jo nemt nok. Men har man 100.000 bånd, er det lidt sværere.
Så burde man måske overveje nogle større bånd.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 21:06 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Det typiske argument for den slags løsninger er, at det ellers er
>> umuligt at garantere en restoretid. Hvis man har 10 bånd, er det
>> jo nemt nok. Men har man 100.000 bånd, er det lidt sværere.
>Så burde man måske overveje nogle større bånd.
Ideen i databasen er kan illustreres med et eksempel:
Lad os sige, at vi har en datamængde på 50 TB, som vi gemmer på
nogle LTO2-bånd (effektivt 200-400 GB/bånd). Vi kører incremental
hver time, og for at holde styr på båndene, kører vi med virtual
tapes (hvert backup-set lægges på et virtuelt bånd, der streames
til fysiske bånd efter behov). Hver times incremental fylder 10
GB. Fuld backup tager vi engang om ugen.
Vi gemmer data i 50 dage, og på grund af ønsket om opløsning er
vi nødt til at gemme alle incrementals undervejs. Den fulde backup
er derfor primært til genskabelse i en disaster-situation.
Med 24 incrementals pr. dag i 50 dage har vi i alt 1.200 virtuelle
tapes at holde styr på. Dertil kommer 7-8 fulde backups, der hver
består af ét virtuelt tape på 50 TB. Det er altså 1.208 virtuelle
bånd.
Datamæssigt har vi 8*50 TB (fulde backups) + 1200*10 GB (incr) =
412 TB data. Det fylder mellem 1000-2000 fysiske bånd.
Her kommer udfordringen så: jeg skal bruge en 20 GB stor fil fra
den 13. i sidste måned, der er så tæt som muligt på kl. 17:23.
Jeg skal bruge den om en time.
What do you do? Tjoh, du spørger din database, og den finder det
rigtige bånd i første hug. Hvis din database ikke er der, har du
tabt. Så skal i princippet søge 1.200 virtuelle bånd igennem, og
de kan i princippet ligge på 2.000 fysiske bånd, som du er nødt
til at pløje igennem fra ende til anden, da der kan være op til
40 virtuelle bånd på ét fysisk bånd.
Mvh.
Klaus.
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 21:16 |
|
Kent Friis <nospam@nospam.invalid> writes:
>>>> Legato Networker, Tivoli Storage Manager, og alle mulige andre
>>>> "rigtige" backupsystemer
>>
>>>Aldrig hørt om dem. Er det sådan noget proprietært skrammel a'la
>>>Windows? :-þ
>>
>> Det er de løsninger, storforbrugere af backup bruger. De er stort
>> set umulige at komme udenom, hvis man har data nok til at skulle
>> bruge robotter.
>Teknisk set svarede du ikke på spørgsmålet.
Sorry - ja, de er kommercielle. Der findes desværre ikke (mig
bekendt) open-source-løsninger i den kaliber.
Mvh.
Klaus.
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 21:19 |
|
Den Sun, 2 Oct 2005 20:15:43 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>>>> Legato Networker, Tivoli Storage Manager, og alle mulige andre
>>>>> "rigtige" backupsystemer
>>>
>>>>Aldrig hørt om dem. Er det sådan noget proprietært skrammel a'la
>>>>Windows? :-þ
>>>
>>> Det er de løsninger, storforbrugere af backup bruger. De er stort
>>> set umulige at komme udenom, hvis man har data nok til at skulle
>>> bruge robotter.
>
>>Teknisk set svarede du ikke på spørgsmålet.
>
> Sorry - ja, de er kommercielle. Der findes desværre ikke (mig
> bekendt) open-source-løsninger i den kaliber.
Der findes heller ikke nogen open-source BSOD-løsninger (hvis vi lige
ser bort fra xscreensaver)...
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 21:21 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Sorry - ja, de er kommercielle. Der findes desværre ikke (mig
>> bekendt) open-source-løsninger i den kaliber.
>Der findes heller ikke nogen open-source BSOD-løsninger (hvis vi lige
>ser bort fra xscreensaver)...
Nu er det jo altså lidt nemmere at undvære både BSOD og screen
saver end en brugbar backupløsning
Mvh.
Klaus.
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 21:23 |
|
Den Sun, 2 Oct 2005 20:20:56 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Sorry - ja, de er kommercielle. Der findes desværre ikke (mig
>>> bekendt) open-source-løsninger i den kaliber.
>
>>Der findes heller ikke nogen open-source BSOD-løsninger (hvis vi lige
>>ser bort fra xscreensaver)...
>
> Nu er det jo altså lidt nemmere at undvære både BSOD og screen
> saver end en brugbar backupløsning
Tja, hvis "brugbar" er det bedste argument for slet ikke at bruge
bånd, så må den være i cirke samme kategori.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 21:28 |
|
Kent Friis <nospam@nospam.invalid> writes:
>Tja, hvis "brugbar" er det bedste argument for slet ikke at bruge
>bånd, så må den være i cirke samme kategori.
Faktisk er virtual-tape-løsningen jo en kombination: alle
virtuelle bånd streames til disk. Når der er behov for det,
off-loades de virtuelle bånd til fysiske bånd, så de kan
flyttes til fjernlokation (hvis ikke robotterne allerede er
placeret der).
Ideen er at give det bedste af to verdener:
* nok disk-cache til at genetablere nye filer (og produktionen
som helhed) i tilfælde af katastrofer) direkte fra disk,
* alle data på bånd med passende database over indholdet, så
ældre data kan restores stort set uden forsinkelse og med
drev-kapacitet og drev-hastighed som eneste begrænsninger
på restore-tid.
Men igen: den slags er man nødt til at betale for. Og de er
ikke billige.
Mvh.
Klaus.
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 21:33 |
|
Den Sun, 2 Oct 2005 20:27:38 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Tja, hvis "brugbar" er det bedste argument for slet ikke at bruge
>>bånd, så må den være i cirke samme kategori.
>
> Faktisk er virtual-tape-løsningen jo en kombination: alle
> virtuelle bånd streames til disk. Når der er behov for det,
> off-loades de virtuelle bånd til fysiske bånd, så de kan
> flyttes til fjernlokation (hvis ikke robotterne allerede er
> placeret der).
>
> Ideen er at give det bedste af to verdener:
Dit argument var ellers at når den database - der kun findes i de
systemer, og ikke med fx tar - ryger, så er båndbackup'en ubrugelig.
"Det bedste"?
> * nok disk-cache til at genetablere nye filer (og produktionen
> som helhed) i tilfælde af katastrofer) direkte fra disk,
Det kunne vi også på arbejdet (dengang jeg havde noget med den slags
at gøre), selvom vi brugte tar. Den kan sagtens skrive til disk.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 21:37 |
|
Kent Friis <nospam@nospam.invalid> writes:
>Dit argument var ellers at når den database - der kun findes i de
>systemer, og ikke med fx tar - ryger, så er båndbackup'en ubrugelig.
>"Det bedste"?
Der findes ikke nogen anden løsning, der ikke bliver ualmindelig
dyr på den ene eller den anden måde. Mig bekendt i hvert fald.
Så snart du hæver datamængden eller frekvensen af incrementals,
må tar og venner give op. De bliver alt for dyre i drift.
Mvh.
Klaus.
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 21:43 |
|
Den Sun, 2 Oct 2005 20:36:39 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Dit argument var ellers at når den database - der kun findes i de
>>systemer, og ikke med fx tar - ryger, så er båndbackup'en ubrugelig.
>
>>"Det bedste"?
>
> Der findes ikke nogen anden løsning, der ikke bliver ualmindelig
> dyr på den ene eller den anden måde. Mig bekendt i hvert fald.
>
> Så snart du hæver datamængden eller frekvensen af incrementals,
> må tar og venner give op. De bliver alt for dyre i drift.
Jeg begynder at blive i tvivl om hvorvidt du stadig argumenterer
for harddisk-backup, eller for store dyre kommercielle
bånd-løsninger...
(Hvor stor var det den hjemme-server der skulle tages backup af den
var?)
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (02-10-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 02-10-05 21:41 |
|
Kent Friis wrote:
> (Hvor stor var det den hjemme-server der skulle tages backup af den
> var?)
160giga, derfor giver det bedst mening at bruge harddiske (hvis vi
antager at den bliver fyldt bare lidt op :)
// Hans
--
Photogallery @ http://nathue.dk
| |
Klaus Ellegaard (02-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 02-10-05 21:46 |
|
Kent Friis <nospam@nospam.invalid> writes:
>Jeg begynder at blive i tvivl om hvorvidt du stadig argumenterer
>for harddisk-backup, eller for store dyre kommercielle
>bånd-løsninger...
Hov, vi har to dele af tråden i gang. Der blev nævnt database-
baserede løsninger (Networker og TSM). Dem har jeg fortalt lidt
om - især hvorfor man ikke kan undvære en database, når mængden
af data stiger.
Som jeg også skrev, egner de sig til løsninger, der skal skalere.
De kan også fint bruges til små hjemmeservere, men det er at skyde
gråspurve med kanoner.
Min mening om hjemmeservere er stadig, at det er totalt umuligt
at konkludere, om harddisk eller bånd er bedst. Der skal meget
mere konkrete oplysninger til, og mængden af data er nærmest
ligegyldigt; det er datasikkerhed og datatype, der er kritisk.
Mvh.
Klaus.
| |
Thorbjoern Ravn Ande~ (02-10-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 02-10-05 22:23 |
|
Klaus Ellegaard <klausellegaard@msn.com> writes:
> Min mening om hjemmeservere er stadig, at det er totalt umuligt
> at konkludere, om harddisk eller bånd er bedst. Der skal meget
> mere konkrete oplysninger til, og mængden af data er nærmest
> ligegyldigt; det er datasikkerhed og datatype, der er kritisk.
Og vi har slet ikke snakket om hvorvidt at backupsoftwaren kan hitte
ud af at sikkerhedskopiere kørende programmer.
Fx skal Oracle lige kildes lidt for at en kopi af dens filer
overhovedet er noget værd.
--
Thorbjørn Ravn Andersen
| |
Thorbjoern Ravn Ande~ (02-10-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 02-10-05 22:18 |
|
Kent Friis <nospam@nospam.invalid> writes:
> Der findes heller ikke nogen open-source BSOD-løsninger (hvis vi lige
> ser bort fra xscreensaver)...
Definer BSOD. Jeg har fx en maskine som Knoppix nægter at starte på
da kernen krasjer.
--
Thorbjørn Ravn Andersen
| |
Kent Friis (03-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 03-10-05 15:32 |
|
Den 02 Oct 2005 23:18:12 +0200 skrev Thorbjoern Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> Der findes heller ikke nogen open-source BSOD-løsninger (hvis vi lige
>> ser bort fra xscreensaver)...
>
> Definer BSOD. Jeg har fx en maskine som Knoppix nægter at starte på
> da kernen krasjer.
Blue Screen of Death.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Klaus Ellegaard (03-10-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 03-10-05 15:33 |
|
Kent Friis <nospam@nospam.invalid> writes:
>> Definer BSOD. Jeg har fx en maskine som Knoppix nægter at starte på
>> da kernen krasjer.
>Blue Screen of Death.
Linux BSOD'er også. Omend B'et sædvanligvis står for "Black".
Mvh.
Klaus.
| |
Kent Friis (03-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 03-10-05 15:37 |
|
Den Mon, 3 Oct 2005 14:33:10 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Definer BSOD. Jeg har fx en maskine som Knoppix nægter at starte på
>>> da kernen krasjer.
>
>>Blue Screen of Death.
>
> Linux BSOD'er også. Omend B'et sædvanligvis står for "Black".
Ah, samme system som når folk omtaler en harddisk, hvor "hard" står
for "hard plastic"?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjoern Ravn Ande~ (02-10-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 02-10-05 21:02 |
|
Klaus Ellegaard <klausellegaard@msn.com> writes:
> Det typiske argument for den slags løsninger er, at det ellers er
> umuligt at garantere en restoretid. Hvis man har 10 bånd, er det
> jo nemt nok. Men har man 100.000 bånd, er det lidt sværere.
Noeh, den er bare 10000 gange stoerre.
Det bliver straks mere boevlet hvis ordet "acceptabel" ogsaa skal
proppes ind i saetningen.
Der er jo firmaer der kan leve af at lave backup for andre. Det er
der nok en grund til.
--
Thorbjørn Ravn Andersen
| |
Martin Hansen (06-10-2005)
| Kommentar
Fra : Martin Hansen |
Dato : 06-10-05 14:38 |
|
Hans Joergensen wrote:
> Nu er du ude i hampen, synes jeg.. den slags uheld sker ikke, og
> hvis den slags uheld sker bør man begrænse sin rootadgang noget
> bedre.
Der skete en kortslutning så der kom 12V på 5v ledningen, på de 100
milisekunder det tog sikringen at brænde af blev halvdelen af alle kredse i
pc'en ødelagt, også et par på HD controleren.
Men nej det sker jo aldrig....
--
Med venlig hilsen/mojn/regards
Martin Hansen
Center for Software Innovation
Stenager 2, DK-6400 Sønderborg, Web: www.cfsi.dk
| |
Klaus Ellegaard (28-09-2005)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-05 05:56 |
|
Kent Friis <nospam@nospam.invalid> writes:
[Disketter]
>> Og på hvilken måde er det et problem med harddiske?
>For mig tager det længere tid at sætte backup-harddisken i maskinen,
>end det gør at sætte en diskette i.
Udgangspunktet i tråden er backup af 160 GB. Lad os bare sige,
at 1% af det ændrer sig om dagen.
I dette tilfælde skal du altså skifte diskette 1.138 gange
om dagen (eller 7 gange med Zip-diske). Vil det virkelig tage
dig kortere tid end at sætte én harddisk til?
Mvh.
Klaus.
| |
Kent Friis (28-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-05 16:03 |
|
Den Wed, 28 Sep 2005 04:56:15 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
> [Disketter]
>>> Og på hvilken måde er det et problem med harddiske?
>
>>For mig tager det længere tid at sætte backup-harddisken i maskinen,
>>end det gør at sætte en diskette i.
>
> Udgangspunktet i tråden er backup af 160 GB. Lad os bare sige,
> at 1% af det ændrer sig om dagen.
>
> I dette tilfælde skal du altså skifte diskette 1.138 gange
> om dagen (eller 7 gange med Zip-diske). Vil det virkelig tage
> dig kortere tid end at sætte én harddisk til?
Kommentaren om disketten blev indledt med "dengang".
*Dengang* fyldte data mindre.
Men hvis vi forestiller os at man kører en fuld backup hver 10. gang,
og så incremental backups ind imellem, så vil det stadig være 10
harddiske (med 1.6 GB på hver, bortset fra den første) der skal søges
igennem for at finde den der indeholder den rigtige backup.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjoern Ravn Ande~ (28-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 28-09-05 18:32 |
|
Kent Friis <nospam@nospam.invalid> writes:
> *Dengang* fyldte data mindre.
Det fyldte da mere :)
En bit i dag fylder meget mindre på en harddisk end det gjorde på en
floppy.
Men der er mere data i dag...
--
Thorbjørn Ravn Andersen
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 06:13 |
|
Kent Friis wrote:
> Men hvis vi forestiller os at man kører en fuld backup hver 10. gang,
> og så incremental backups ind imellem, så vil det stadig være 10
> harddiske (med 1.6 GB på hver, bortset fra den første) der skal søges
> igennem for at finde den der indeholder den rigtige backup.
Men hvorfor i alverden skulle man køre fuld backup hver 10. gang?
Man har jo en fuld backup hver dag, der blot gemmer slettede/ændrede filer
i et andet directory :)
// Hans
--
Photogallery @ http://nathue.dk
| |
Kent Friis (29-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-05 15:39 |
|
Den 29 Sep 2005 05:13:14 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Men hvis vi forestiller os at man kører en fuld backup hver 10. gang,
>> og så incremental backups ind imellem, så vil det stadig være 10
>> harddiske (med 1.6 GB på hver, bortset fra den første) der skal søges
>> igennem for at finde den der indeholder den rigtige backup.
>
> Men hvorfor i alverden skulle man køre fuld backup hver 10. gang?
> Man har jo en fuld backup hver dag, der blot gemmer slettede/ændrede filer
> i et andet directory :)
Hvordan gemmer du i et andet directory på en off-site harddisk?
Uden at lave udfordre Murphy ved at tilslutte den?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (29-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 29-09-05 19:03 |
|
Kent Friis wrote:
>> Men hvorfor i alverden skulle man køre fuld backup hver 10. gang?
>> Man har jo en fuld backup hver dag, der blot gemmer slettede/ændrede filer
>> i et andet directory :)
> Hvordan gemmer du i et andet directory på en off-site harddisk?
rsync --backup-dir ?
> Uden at lave udfordre Murphy ved at tilslutte den?
?
// Hans
--
Gumminumser == Champignons
| |
Kent Friis (29-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-05 21:23 |
|
Den 29 Sep 2005 18:02:30 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>>> Men hvorfor i alverden skulle man køre fuld backup hver 10. gang?
>>> Man har jo en fuld backup hver dag, der blot gemmer slettede/ændrede filer
>>> i et andet directory :)
>> Hvordan gemmer du i et andet directory på en off-site harddisk?
>
> rsync --backup-dir ?
Du mener rsync --backup-dir -e /bin/taxi irl://nørregade_7 ?
>> Uden at lave udfordre Murphy ved at tilslutte den?
>
> ?
Hvis disken sidder i maskinen, er den ikke en sk*d mere backup end
den disk der sidder i maskinen. Sletter man den, er den umulig at
restore fra. Og det er netop i det tilfælde at man har brug for
en backup.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (30-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 30-09-05 00:39 |
|
Kent Friis wrote:
> Hvis disken sidder i maskinen, er den ikke en sk*d mere backup end
> den disk der sidder i maskinen. Sletter man den, er den umulig at
> restore fra. Og det er netop i det tilfælde at man har brug for
> en backup.
Hvad hvis disken sidder i en mindre maskine der står på Nørregade 7,
og man syncer til den hver nat?
// Hans
--
http://ph33r.dk - Vejen til et fjollet liv
| |
Kent Friis (30-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-05 15:04 |
|
Den 29 Sep 2005 23:39:07 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Hvis disken sidder i maskinen, er den ikke en sk*d mere backup end
>> den disk der sidder i maskinen. Sletter man den, er den umulig at
>> restore fra. Og det er netop i det tilfælde at man har brug for
>> en backup.
>
> Hvad hvis disken sidder i en mindre maskine der står på Nørregade 7,
> og man syncer til den hver nat?
Så er den ikke en sk*d mere backup end enhver anden maskine på
netværket.
Og uanset er det ikke et argument får harddiske i forhold til bånd.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (02-10-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 02-10-05 08:48 |
|
Kent Friis wrote:
> Og uanset er det ikke et argument får harddiske i forhold til bånd.
Okay, så prøver vi en anden.
Kan du forklare mig hvordan du ville bygge en fornuftig
backupløsning der kan klare backup 2-3 uger tilbage af 2TB data,
budgettet er 50000kr (lad os bare sige uden moms).
// Hans
--
http://ph33r.dk - Helt galt .. :)
| |
Kent Friis (02-10-2005)
| Kommentar
Fra : Kent Friis |
Dato : 02-10-05 20:31 |
|
Den 02 Oct 2005 07:48:03 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Og uanset er det ikke et argument får harddiske i forhold til bånd.
>
> Okay, så prøver vi en anden.
>
> Kan du forklare mig hvordan du ville bygge en fornuftig
> backupløsning der kan klare backup 2-3 uger tilbage af 2TB data,
> budgettet er 50000kr (lad os bare sige uden moms).
Det er samme argument som jeg for snart en uge siden skrev var det
bedste argument for HD-backup: prisen.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjoern Ravn Ande~ (27-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 27-09-05 21:03 |
|
Kent Friis <nospam@nospam.invalid> writes:
> Men så gik det op for en hvor lang tid det tager at finde den
> nyeste udgave af den fil man er kommet til at slette, når man ikke lige
> kan huske hvornår man sidst har ændret den, og dermed hvilken disk
> den ligger på.
Prøv du at lege lidt med Amanda - det er ret fikst.
Vær dog opmærksom på at man skal være ret omhyggelig for at få det til
at fungere som det skal.
--
Thorbjørn Ravn Andersen
| |
Kent Friis (27-09-2005)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-05 21:17 |
|
Den 27 Sep 2005 22:03:18 +0200 skrev Thorbjoern Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> Men så gik det op for en hvor lang tid det tager at finde den
>> nyeste udgave af den fil man er kommet til at slette, når man ikke lige
>> kan huske hvornår man sidst har ændret den, og dermed hvilken disk
>> den ligger på.
>
> Prøv du at lege lidt med Amanda - det er ret fikst.
Næ tak, det lader jeg arbejdsformidlingen om. Kører det iøvrigt ikke
stadig kun på OS/2?
> Vær dog opmærksom på at man skal være ret omhyggelig for at få det til
> at fungere som det skal.
Jo tak, det har jeg læst om.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjoern Ravn Ande~ (28-09-2005)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 28-09-05 01:04 |
|
Kent Friis <nospam@nospam.invalid> writes:
> > Prøv du at lege lidt med Amanda - det er ret fikst.
>
> Næ tak, det lader jeg arbejdsformidlingen om. Kører det iøvrigt ikke
> stadig kun på OS/2?
Godt spørgsmål. Prøv du at spørge Google om det.
--
Thorbjørn Ravn Andersen
| |
Claus Alboege (28-09-2005)
| Kommentar
Fra : Claus Alboege |
Dato : 28-09-05 01:20 |
|
Thorbjoern Ravn Andersen <nospam0000@gmail.com> writes:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> Men så gik det op for en hvor lang tid det tager at finde den
>> nyeste udgave af den fil man er kommet til at slette, når man ikke lige
>> kan huske hvornår man sidst har ændret den, og dermed hvilken disk
>> den ligger på.
>
> Prøv du at lege lidt med Amanda - det er ret fikst.
Og skulle man bliv traet af Amandas begraensninger, kan man tage et kig
paa Bacula.
http://www.bacula.org/
/Claus A
| |
Allan Madsen (27-09-2005)
| Kommentar
Fra : Allan Madsen |
Dato : 27-09-05 16:54 |
|
Ja den med den ekstra disk var måske en idé
Men er der ikke noget med af man kun kan have en ide disk (ata) og to
sata disk og de to sata skal jo køre en raid (spejling) er det ikke raid 5??
Allan Madsen wrote:
> Hejsa
>
> Jeg vil gerne have en linux server op at stå, den skal kun funger som
> fil server for et vindows netværk og som mail henter (fetchmail??).
>
> Den skulle gerne kører noget raid (sata)? med f.eks 160Gb disk plads.
>
> Desuden skal der en tape streamer i. (Rigtige mænd er begyndt at tage
> backup *g*)
>
> Der er intet krav til noget grafisk, og det er kun ca 5 windows klienter
> der skal koble op mod den.
>
> Har i nogle forslag til hviken hardware der skal i for at det hele kan
> spille sammen??
>
> Og hvilken backup software der vil være godt at kunne kører på den???
>
>
> MVH
> Allan Madsen
| |
Hans Joergensen (27-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 27-09-05 19:21 |
|
Allan Madsen wrote:
> Men er der ikke noget med af man kun kan have en ide disk (ata) og to
> sata disk og de to sata skal jo køre en raid (spejling) er det ikke raid 5??
spejling er RAID1, og man kan have 2 IDE-diske per kanal hvis der er
tale om normal IDE og en disk per kabel med SATA, controllere koster i
øvrigt ikke alverden.
// Hans
--
Leveret af http://enterprise-server.dk
"Vejen til en professionel løsning"
| |
Allan Madsen (27-09-2005)
| Kommentar
Fra : Allan Madsen |
Dato : 27-09-05 21:42 |
|
Så er jeg kommet frem til hvilken hardware der skal i.
Det bliver en rod disk på et ata stik.
2 sata diske i Raid 1 konf.
Samt en dvd brænder dual layer til backup.
Nu vil jeg så gerne hører om hvilken hardware man skal bruge / udgå for
at få det hele til at spille sammen?
Nogle gode forslag.??
MVH
Allan Madsen
Allan Madsen wrote:
> Hejsa
>
> Jeg vil gerne have en linux server op at stå, den skal kun funger som
> fil server for et vindows netværk og som mail henter (fetchmail??).
>
> Den skulle gerne kører noget raid (sata)? med f.eks 160Gb disk plads.
>
> Desuden skal der en tape streamer i. (Rigtige mænd er begyndt at tage
> backup *g*)
>
> Der er intet krav til noget grafisk, og det er kun ca 5 windows klienter
> der skal koble op mod den.
>
> Har i nogle forslag til hviken hardware der skal i for at det hele kan
> spille sammen??
>
> Og hvilken backup software der vil være godt at kunne kører på den???
>
>
> MVH
> Allan Madsen
| |
Hans Joergensen (28-09-2005)
| Kommentar
Fra : Hans Joergensen |
Dato : 28-09-05 03:33 |
|
Allan Madsen wrote:
> Så er jeg kommet frem til hvilken hardware der skal i.
> Det bliver en rod disk på et ata stik.
> 2 sata diske i Raid 1 konf.
> Samt en dvd brænder dual layer til backup.
> Nu vil jeg så gerne hører om hvilken hardware man skal bruge / udgå for
> at få det hele til at spille sammen?
> Nogle gode forslag.??
I den størrelsesorden er det næsten lige meget.
Men husk at holde dig fra "hardware"-RAIDcontrollere, de er altid(næsten)
besværlige at få til at virke ordentligt, og alligevel er software-RAID
meget nemmere at have med at gøre, og altid hurtigere.
Det gør naturligvis ikke noget at en sådan controller eksisterer,
man kan bare lade være med at bruge den
Skal maskinen stå et sted hvor der kommer mennesker?
I så fald ville jeg holde mig fra en decideret server-maskine da de
altid larmer p**** meget.
En fornuftig standard PC - evt med et par ekstra 80mm-blæsere eller
hvad der nu er plads til - vil i langt de fleste tilfælde snildt kunne
gøre det.
Beklager i øvrigt at jeg har været med til at rode din tråd til med
alt muligt udenomssnak
// Hans
--
Jeg - og andre - bliver gladest hvis man følger retningslinierne
på http://www.usenet.dk/netikette/ .. på forhånd tak :)
| |
Peter Larsen (29-09-2005)
| Kommentar
Fra : Peter Larsen |
Dato : 29-09-05 07:49 |
|
Allan Madsen wrote:
[backup]
Jeg kan fortælle dig hvad jeg bruger, og hvorfor det er smart..
BACULA:
Virker på både windows og linux/bsd. laver full backup (d. første lørdag i
måneden) og incidimental resten af den.. hver lørdag laves en
"lørdag-lørdag" backup. (default opsætning).
Det er smart fordi: det er en "ægte backup, når det er sat op kører det
bare.. du kan lave en restore til "metal" (skal dog have det efterprøvet,
har kun før brugt det til enkeltfils restore)
RDIFF-backup
også kendt som "rsync diff backup", du tager een backup, og differ dig
derudaf derefter.
Med lidt shellscripting kan du nemt lave en fullbackup hver den første ud af
det hvor du sletter feks 6 måneder gammel backup
Som default er rdiff MEGET pladsøkonomisk.. HUSK AT TJEKKE EXITCODE I DIT
SCRIPT!
HUSK:
At tage backup ud af huset
At dumpe (my)sql til en fil
Test restore og nedskriv det FØR du får brug for det
Jeg bruger begge systemer på hver af mine kritiske setups.. De har redet min
røv mere end een gang
--
Regards, Peter Larsen - GratisDNS.dk / MXHotel.dk / Domæne.dk / NetPlads.dk
| |
|
|