|
|
 | backup over ADSL
Fra : Leonard |
Dato : 13-10-03 16:42 |
|
Jeg vil gerne tage backup på en filserver og derefter overføre
backuppen til en anden filserver. Begge filservere er forbundet til
internettet via ADSL.
Hvordan gøres det nemt og sikkert?
- hint til programmer og guides vil hjælpe meget.
--
med venlig hilsen
Leonard - http://leonard.dk/
| |
 Klaus Ellegaard (13-10-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 13-10-03 17:33 |
|
Leonard <dennemailerikketilspam@tdc-broadband.dk> writes:
>Jeg vil gerne tage backup på en filserver og derefter overføre
>backuppen til en anden filserver. Begge filservere er forbundet til
>internettet via ADSL.
>Hvordan gøres det nemt og sikkert?
>- hint til programmer og guides vil hjælpe meget.
En fuld backup pr. uge/måned/år og derefter incrementals. Til det
er "tar" udmærket. En udmærket måde kunne være at have et ugentligt
cronjob, der laver...
mkdir -p /var/backup
chown root:other /var/backup
chmod 700 /var/backup
date > /var/backup/last_backup
tar zcf /var/backup/full-`date +%j`.tar.gz /home
Det giver en fin backup af home i /var/backup/full-286.tar.gz -
hvor 286 er dagens nummer i året.
Resten af ugens dage en incremental:
[ -r /var/backup/last_backup ] &&
tar --newer `cat /var/backup/last_backup` -zcf \
/var/backup/incr-`date +%j`.tar.gz /home
Det giver en tarball med ændringer siden sidste fulde backup.
Og så er det ellers bare at bruge rsync eller tilsvarende til
at flytte filerne over på den anden maskine. Måske et par jobs
til at rydde op hen ad vejen heller ikke ville være en dårlig
plan (eller lad rsync gøre det).
Detaljen med ovenstående er, at det kun virker med GNU tar. I
fald man har en almindelig tar, skal man droppe "-z" og pakke
filen bagefter ("tar cf - /home | gzip -c > filnavn.tar.gz").
tar understøtter heller ikke "--newer", men så kan man lave
noget à la:
find /home -newer /var/backup/last_backup -type f \
> /var/backup/filliste
[ -r /var/backup/filliste ] &&
tar -I /var/backup/filliste -cf - |
gzip -c /var/backup/incr-`date +%j`.tar.gz
Så skulle det virke. Den tager godtnok ikke tomme directories,
links og special files med, så måske den find skal udbygges lidt.
Konceptet er godt nok.
Det skal lige siges, at jeg ikke har afprøvet ovenstående, så
trykfejl og forglemmelser må man lige selv fikse.
Mvh.
Klaus.
PS! HUSK NU den chown+chmod på /var/backup. Det nytter ikke, at
brugerne ikke har adgang til hinandens filer, hvis de selv kan
suge hinandens ting ud fra /var/backup/*. Afhængig af paranoiditet
bør man måske også tjekke for symlinks og den slags, men så bliver
dether en lang artikel.
| |
Klaus Ellegaard (13-10-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 13-10-03 17:35 |
|
Klaus Ellegaard <klausellegaard@msn.com> writes:
> gzip -c /var/backup/incr-`date +%j`.tar.gz
Prøv med
gzip -c > /var/backup/incr-`date +%j`.tar.gz
i stedet.
Mvh.
Klaus.
| |
Leonard (13-10-2003)
| Kommentar
Fra : Leonard |
Dato : 13-10-03 18:13 |
|
Klaus Ellegaard <klausellegaard@msn.com> wrote:
>Afhængig af paranoiditet
>bør man måske også tjekke for symlinks og den slags, men så bliver
>dether en lang artikel.
Tak skal du have, det ser jo meget nemt ud 
Nu har jeg i hvert fald noget at gå igang med.
--
med venlig hilsen
Leonard - http://leonard.dk/
| |
Rune Friis Jørgensen (13-10-2003)
| Kommentar
Fra : Rune Friis Jørgensen |
Dato : 13-10-03 23:39 |
|
"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bmek3f$65o$1@katie.ellegaard.dk...
> Leonard <dennemailerikketilspam@tdc-broadband.dk> writes:
>
> >Jeg vil gerne tage backup på en filserver og derefter overføre
> >backuppen til en anden filserver. Begge filservere er forbundet til
> >internettet via ADSL.
> >Hvordan gøres det nemt og sikkert?
> >- hint til programmer og guides vil hjælpe meget.
>
> En fuld backup pr. uge/måned/år og derefter incrementals. Til det
> er "tar" udmærket. En udmærket måde kunne være at have et ugentligt
> cronjob, der laver...
Vil du så overføre _alt_ en gang om ugen/måneden/året? Tosset...
Og hvorfor spilde plads på "original-serveren" til at lave en tar?
Og hvorfor bruge incremental backup?
Selvfølgelig kan tar komprimere, men det kan rsync også!
Og jeg tør godt formode at de data der skal tages backup af i høj grad vil
være de samme. Og så er der jo ingen grund til at overføre dem mere end en
gang.
Jeg laver backup af firmaets server hjem til min hjemmeserver, der er tale
om ca 12 GB. En backup tager typisk 1 time.
Anbefalet løsning:
1) Brug rsync til at overføre filerne med således at du har en komplet
backup.
rsync kan selv finde ud af hvilke filer der er ændret.
2) Lav lokal backup for at bevare data i flere generationer.
faubackup kan lave 50 gange backup af de samme data, og stadig ikke fylde
mere end en kopi af originalen.
Hvis harddisk plads er en begrænsning i modtager enden (den anbefalede
løsning bruger jo også meget plads til at lave tar-filerne) og man ikke
ønsker at have data liggende 2 steder på samme server, kan man jo opnå lidt
sikkerhed ved at køre rsync uden "--delete". Eller i hvert tilfælde kun køre
"--delete" umiddelbart efter backup af backup'en.
Men til den lokale backup, kan jeg anbefale "faubackup".
Her kan du tillade dig at lave daglige komplette backup'er uden at det vil
kræve ekstra plads.
Programmet "linker" simpelthen dagens backup til de originale filer.
Slettes de originale filer vil det kun være originalens "henvisning" til
filen der fjernes.
Således slettes data først når der ikke er flere henvisninger til dem.
Fra brugerens (din) side ligner dags-backup'en en komplet kopi.
Jeg har således præsteret at have flere hundrede GB på en lille disk og
stadig have masser af ledig plads.
Rune
| |
 Klaus Ellegaard (14-10-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 14-10-03 07:17 |
|
"Rune Friis Jørgensen" <rune_friis@adslhome.dk> writes:
>> En fuld backup pr. uge/måned/år og derefter incrementals. Til det
>> er "tar" udmærket. En udmærket måde kunne være at have et ugentligt
>> cronjob, der laver...
>Vil du så overføre _alt_ en gang om ugen/måneden/året? Tosset...
Er det tosset at overføre 50 MB om ugen?
Mvh.
Klaus.
| |
Rune Friis Jørgensen (14-10-2003)
| Kommentar
Fra : Rune Friis Jørgensen |
Dato : 14-10-03 09:30 |
|
"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bmg4d3$kpu$1@katie.ellegaard.dk...
> "Rune Friis Jørgensen" <rune_friis@adslhome.dk> writes:
>
> >> En fuld backup pr. uge/måned/år og derefter incrementals. Til det
> >> er "tar" udmærket. En udmærket måde kunne være at have et ugentligt
> >> cronjob, der laver...
>
> >Vil du så overføre _alt_ en gang om ugen/måneden/året? Tosset...
>
> Er det tosset at overføre 50 MB om ugen?
Selvfølgelig ikke.
Men hvis man har en filserver, så er det vel næsten en naturlov at der
hurtigt bliver hældt adskillige GB på sådan en.
Og jeg ved da godt at selv en GB hurtigt er overført med ADSL. selv 128 kbit
upload giver 1 GB i døgnet.
Men når nu rsync er så god til netop dette, kan jeg ikke se hvorfor man vil
begynde på alle mulige krumspring med hjemmelavede scripts mv.
Rune
| |
Klaus Ellegaard (14-10-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 14-10-03 09:49 |
|
"Rune Friis Jørgensen" <rune_friis@adslhome.dk> writes:
>Men når nu rsync er så god til netop dette, kan jeg ikke se hvorfor man vil
>begynde på alle mulige krumspring med hjemmelavede scripts mv.
Det krævede opgaven jo:
> Jeg vil gerne tage backup på en filserver og derefter overføre
> backuppen til en anden filserver.
Hvor ligger den lokale backup, hvis man bruger din metode?
Mvh.
Klaus.
| |
Rune Friis Jørgensen (15-10-2003)
| Kommentar
Fra : Rune Friis Jørgensen |
Dato : 15-10-03 00:36 |
|
"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bmgda1$nnu$1@katie.ellegaard.dk...
> "Rune Friis Jørgensen" <rune_friis@adslhome.dk> writes:
>
> >Men når nu rsync er så god til netop dette, kan jeg ikke se hvorfor man
vil
> >begynde på alle mulige krumspring med hjemmelavede scripts mv.
>
> Det krævede opgaven jo:
>
> > Jeg vil gerne tage backup på en filserver og derefter overføre
> > backuppen til en anden filserver.
>
> Hvor ligger den lokale backup, hvis man bruger din metode?
>
På en seperat disk.
Min primære backup ville være den lokale. Denne ville jeg også gemme i flere
generationer.
Backup'en ud af huset er mere tænkt i tilfælde at
tyveri/brand/vandskade/elskade mv.
Jeg skulle mene at det største behov for indlæsningen af backupen opdages
ret hurtigt.
Dette være som følge af utilsigtet sletning/overskrivning af data eller
virus.
Her ville jeg bruge den lokale backup.
I tilfælde af brand e.l. kan man vel nok klare at miste op til en uges
arbejde?
Ved at tage fjern-backup af lokal-backupen kan man også være sikker på at
der ikke ændres i dataene mens overførslen finder sted.
Rune
| |
Troels Arvin (14-10-2003)
| Kommentar
Fra : Troels Arvin |
Dato : 14-10-03 11:34 |
|
On Mon, 13 Oct 2003 17:42:02 +0200, Leonard wrote:
> Jeg vil gerne tage backup på en filserver og derefter overføre
> backuppen til en anden filserver. Begge filservere er forbundet til
> internettet via ADSL.
rdiff-backup er perfekt til dette formål; bruger det selv til at back'e
en håndfuld servere op over ADSL. Første backup tager et godt stykke
tid, mens efterfølgende backups kun tager ændringerne med (bruger her
samme algoritmer som rsync, i og med at den benytter librsync). Desuden
gemmes ændringer tilbage i tiden, således at du kan bede om at få
reetableret fil XXX på tidspunkt yyyy-yy-yy, alt efter hvor længe du
gemmer ændringer.
Kræver i praksis, at du har godt tjek på, hvorledes nøgle-baseret
bruger-validering med nøgler. Er i det hele taget ikke helt så let at
få installeret som fx. rsync (der følger med de fleste open source
operativsystemer nu om dage), bl.a. fordi den kræver, at en relativt ny
version af Python er installeret.
Restore-procedure kan være lidt langhåret.
Mailing-list spørgsmål giver hurtige svar.
http://rdiff-backup.stanford.edu/
Sig til, hvis du vil have et eksempel-script til, hvorledes backup kan
foregå.
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Klaus Kolle (15-10-2003)
| Kommentar
Fra : Klaus Kolle |
Dato : 15-10-03 08:53 |
|
On Tue, 14 Oct 2003 12:33:58 +0200, Troels Arvin <troels@arvin.dk>
wrote:
>
>> Jeg vil gerne tage backup på en filserver og derefter overføre
>> backuppen til en anden filserver. Begge filservere er forbundet til
>> internettet via ADSL.
>
>rdiff-backup er perfekt til dette formål; bruger det selv til at back'e
>en håndfuld servere op over ADSL. Første backup tager et godt stykke
[8<]
>
>Sig til, hvis du vil have et eksempel-script til, hvorledes backup kan
>foregå.
Synes dette lyder interessant - kunne godt tænke mig et eksempel
script til at tage udgangspunkt i.
mvh
Klaus Kolle
| |
Troels Arvin (15-10-2003)
| Kommentar
Fra : Troels Arvin |
Dato : 15-10-03 11:06 |
|
On Wed, 15 Oct 2003 09:52:50 +0200, Klaus Kolle wrote:
>>Sig til, hvis du vil have et eksempel-script til, hvorledes backup kan
>>foregå.
>
> Synes dette lyder interessant - kunne godt tænke mig et eksempel
> script til at tage udgangspunkt i.
OK; har lagt et eksempel-script på
http://troels.arvin.dk/rdiff-backup/perform-backup
Scriptet er næsten som ét af dem, jeg benytter; dog justeret en anelse,
så principielt er scriptet ikke testet.
Inden du kan nå så langt som til at bruge scriptet, skal du have opsat
SSH, således at du fra backup-maskinen kan ssh'e ind som root på de
maskiner, der skal back'es op. Du behøver principielt ikke at arbejde som
root på den maskine, hvorfra scriptet køres (og backup-data gemmes).
Se også:
http://groups.google.com/groups?selm=pan.2003.10.03.21.49.50.618154%40arvin.dk&output=gplain
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Klaus Kolle (17-10-2003)
| Kommentar
Fra : Klaus Kolle |
Dato : 17-10-03 07:03 |
|
On Wed, 15 Oct 2003 12:05:45 +0200, Troels Arvin <troels@arvin.dk>
wrote:
>On Wed, 15 Oct 2003 09:52:50 +0200, Klaus Kolle wrote:
>
>>>Sig til, hvis du vil have et eksempel-script til, hvorledes backup kan
>>>foregå.
>>
>> Synes dette lyder interessant - kunne godt tænke mig et eksempel
>> script til at tage udgangspunkt i.
>
>OK; har lagt et eksempel-script på
> http://troels.arvin.dk/rdiff-backup/perform-backup
>
Tak skal du have - jeg ser på det og vil forsøge at tilpasse det til
mit behov.
Klaus Kolle
| |
|
|