Daglig backup af vigtige filer

[laoshi]

Det viste sig at der var mere i sagen end blot at putte sine scripts ind i ovennævnte mapper. Men som en følge af arbejdet med at få det til at fungere har jeg sammen med christian.arvai fundet frem til en rimeligt enkel procedure som virker med de scripts man gerne vil have til at køre på forubestemte tidspunkter.
Guiden til det findes her: https://ubuntudanmark.dk/forum/viewtopic.php?f=11&t=6043

[laoshi]

Nu hvor tiden nærmer sig hvor mange går over til 9.04 er spørgsmålet om backup aktuelt igen. Jeg bruger selv det script som er angivet i denne guides første indlæg. Og det har reddet mig fra en del ærgrelser allerede.
Hvis man nu ikke er så meget til scripts, så har jeg nu tilføjet en afdeling af guiden til installation af det grafiske backup-program Backintime. Det er enkelt at installere, let at bruge, og det bygger på samme udmærkede backupprogram som scriptet.
Så hvis du ikke allerede har en velfungerende backup-løsning, så tag lige og kig på de to muligheder i guiden!

[zob]

Tusind tak for denne laoshi. Det virker... næsten da.
Jeg har sikkert bare skrevet noget forkert. Det eneste jeg har ændret i scriptet er stien til min eksterne HD som skal huse backup'en.

Kode: Vælg alt

# Backup af /etc/ i den aktuelle udgave. Den aktuelle udgave gemmes i usr, ændrede/slettede filer gemmes i en etc-mappe med ugedagens navn
echo ""
echo "Backup af etc til ekstern disk"
echo ""
rsync -vrtplz --progress --stats --delete --backup --backup-dir=/media/LinuxBackExt3/etc-`date +%A` /etc/ /media/LinuxBackExt3/etc

# Backup af /usr/ i den aktuelle udgave. Den aktuelle udgave gemmes i usr, ændrede/slettede filer gemmes i en usr-mappe med ugedagens navn
echo ""
echo "Backup af usr til ekstern disk"
echo ""
rsync -vrtplz --progress --stats --delete --backup --backup-dir=/media/LinuxBackExt3/usr-`date +%A` /usr/ /media/LinuxBackExt3/usr

# Backup af brugers /home/ den aktuelle udgave gemmes i aktuel_backup, ændrede/slettede filer gemmes i en mappe med ugedagens navn
echo ""
echo "Backup af home til ekstern disk"
echo ""
rsync -vrtplz --progress --stats --delete --backup --backup-dir=/media/LinuxBackExt3/$HOME-`date +%A` $Home/ /media/LinuxBackExt3/aktuel_backup

Der kan du se min.
Jeg antager at det eneste den bør lave backup af er /etc/ og /usr/ og /home/.
Det er da også der den starter. Men den forsætter altså ind i /media/* og her er der jo nok at tage fat på for her er alle harddiske jo mountet. Dvs. den begynder bare at tage kopier at alle harddiske. Der stoppede jeg den. Jeg er dog lidt spændt på hvad der mon ville være sket når den kom til sige selv, og skulle tage backup af den harddisk den var ved at skrive backup til. Ouroboros!
Men altså. Kan du være behjælpelig med at finde ud af hvorfor den ikke nøjedes med de mapper jeg har nævnt? Eller er det måske meningen at den skal tage backup af alt? I så fald hvordan kan jeg ændre scriptet?

Tusind Tak. Og tak for at du deler så rundhåndet ud at din personlige toolbox.

[laoshi]

Eller er det måske meningen at den skal tage backup af alt?

- nej, det er det bestemt ikke. Det vigtigste er jo alle ens brugerfiler i /home.
backup af etc er knap så vigtigt, da det meste kan geninstalleres automatisk, men jeg tager den med da jeg har konfigureret min apache-server og oplysningerne herom ligger i etc (at resten så også kommer med betyder ikke meget rent pladsmæssigt)
jeg har selv reduceret backup af usr til /usr/local/bin hvor jeg har personligt tilpassede scripts til at ligge

Men hvorfor backup'en kører i en uendelig sløjfe (måske!) for dig, kan jeg ikke lige regne ud fra dit citat af scriptet. Umiddelbart ser de jo identiske ud, bortset fra disk-navnet. Og jeg har mit backupscript til at køre automatisk hver dag uden uforudsete problemer.

Mit forslag er at du tager hver kommando for sig fra skriptet og prøver at køre fra terminalen med sudo foran:

Kode: Vælg alt

sudo rsync -vrtplz --progress --stats --delete --backup --backup-dir=/media/LinuxBackExt3/etc-`date +%A` /etc/ /media/LinuxBackExt3/etc

Kode: Vælg alt

sudo rsync -vrtplz --progress --stats --delete --backup --backup-dir=/media/LinuxBackExt3/usr-`date +%A` /usr/ /media/LinuxBackExt3/usr

og

Kode: Vælg alt

sudo rsync -vrtplz --progress --stats --delete --backup --backup-dir=/media/LinuxBackExt3/$HOME-`date +%A` $Home/ /media/LinuxBackExt3/aktuel_backup

kør dem en ad gangen og se hvordan det arter sig.
Og skriv endelig tilbage om hvad du finder ud af!

[zob]

Tak for det hurtige svar.
Jeg vil følge dit råd. Jeg tror dog jeg kan gætte udfaldet på forhånd for jeg fulgte jo med stor spænding med i terminalen da jeg prøvede det første gang i går. Den kører i script-rækkefølgen. Jeg er ret sikkert på at /etc og /usr scriptene forløb efter hensigten. Det var først efter den havde kørt /home (inkl. usynlige filer og mapper selvfølgelig) at den tog hul på det der nu var mountet i root kan jeg se nu når jeg kikker på min eksterne. De er der alle sammen: /bin, /boot, /cdrom, /dev, /etc, /home, /lib, /lost+found osv, osv.
Men jeg prøver lige en af gangen.

[zob]

Det ser ud til at /etc/ og /usr/ kommandoerne kører fint som forventet.
/home/ kommandoen giver dog dynger af fejlmeddelelser.
De fleste af dem hedder noget i stil med:

Kode: Vælg alt

rsync: failed to set times on "/media/LinuxBackExt3/aktuel_backup/dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J1QY619151": Operation not permitted (1)

Og sådan nogen får jeg for alle harddiske og partitions tror jeg det er.
Desuden får jeg en del fejl der ser ud som følger:

Kode: Vælg alt

rsync: recv_generator: mkdir "/media/LinuxBackExt3/aktuel_backup/home/lars/.evolution/tasks/local/system" failed: Permission denied

Det er måske fordi jeg havde evolution åben, da jeg kørte kommandoen.

Hvad med denne her:

Kode: Vælg alt

rsync: recv_generator: failed to stat "/media/LinuxBackExt3/aktuel_backup/home/lars/.gnupg/gpg.conf": Permission denied (13)

Dem er der også mange af (som ligner i hvert fald).

Men alle disse permission fejl kan jo være fordi at /home kommandoen, til forskel fra de andre to ikke havde sudo foranstillet. Skulle den have haft det.

Og den er gået i gang med ting uden for /home/. Og det tror jeg den ville have gjort sudo eller ej.

Det eneste sted jeg kan se en forskel er at /usr/ og /etc/ i deres respektive kommandoer ser netop sådan ud - altså med slash foran. $home/ derimod har et dollartegn. Det kan da ikke være det der gør forskellen, eller hvad?

[laoshi]

$home/ derimod har et dollartegn

- det er bare en enklere notation af /home/brugernavn/
Edit: Det er ikke rigtigt. Men det er derimod $HOME - og som det fremgår af det følgende i tråden er det netop denne fejlskrivning som får uventede konsekvenser

Kode: Vælg alt

Men alle disse permission fejl kan jo være fordi at /home kommandoen, til forskel fra de andre to ikke havde sudo foranstillet. Skulle den have haft det.

- ja, det skulle den, min (copy-paste) fejl!
Så permissions-fejlmeldingerne burde forsvinde, når du bruger sudo.

Men nogle af fejlmeldingerne er interessante:

rsync: failed to set times on "/media/LinuxBackExt3/aktuel_backup/dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J1QY619151": Operation not permitted (1)

- det må der vist tænkes lidt nærmere over.
Jeg kan ikke rigtig se hvorfor /dev/disk/osv. bliver taget med. Har du en /dev/ mappe i din /home?
Hvis det er tilfældet så er det også muligt at undtage bestemte mapper fra at blive overført - men det skal jeg lige læse lidt på.

[zob]

Hmmm. Meget mærkeligt.
Det hjalp selvfølgelig på alle permission-fejlene at give sudo kommandoen.
Men hvad er det den laver her:

Kode: Vælg alt

dev/.udev/names/tty61/
dev/.udev/names/tty61/\x2fdevices\x2fvirtual\x2ftty\x2ftty61
           0 100%    0.00kB/s    0:00:00 (xfer#545, to-check=1215/2854)


Og så du kan se er det ikke kun andre devices den kaster sig over. Det gælder f.eks. også /lib/ mappen i root. Det er bare et eksempel ud af mange (eller ud af alle rettere sagt). Det gælder også for følgende udpluk. Blot et eksempel:

Kode: Vælg alt

lib/modules/2.6.28-11-generic/volatile/
lib/modules/2.6.28-11-generic/volatile/.mounted
           0 100%    0.00kB/s    0:00:00 (xfer#950, to-check=1049/15706)


Jeg kan bare ikke forstå det. Men i fejlfindingsøjemed er det klart at hvis scriptet ellers er korrekt, også det ser unægtelig sådan ud, ja så er det vel opsætningen af mit OS der betyder at jeg får et andet resultat end dig når jeg kører det.
Og det virker rigtigt at tænke som du gør, at den hos mig, på en eller anden vis bliver ført videre fra /home/ og tilbage til root (at mit root filsystem på en eller anden vis er inkluderet/mounted i /home), måske gennem en /dev/ mappe i min /home/. Sådan en har jeg dog ikke.

Her følger indholdet af min hjemmemappe (inkl. skjulte mapper) fra kommandoen ls -a:

Kode: Vælg alt

.              .bogofilter            .dmrc            .esd_auth         .gconfd          .gpilotd         .java                 Musik                .pulse-cookie        .solfege                   .update-notifier  .xine
..             .cache                 Dokumenter       .evolution        .gegl-0.0        .gpilotd.pid     .local                .nautilus            .qt                  .solfegerc                 Videoklip         .xsession-errors
.adobe         .compiz                download         .exaile           .gimp-2.6        .gstreamer-0.10  .lyrics               Offentligt           .recently-used       .songbird2                 .VirtualBox
.aptitude      .config                DrLive-VLC.xspf  examples.desktop  .gksu.lock       .gtk-bookmarks   .macromedia           .openoffice.org      .recently-used.xbel  .sudo_as_admin_successful  .Wammu
.bash_history  .crash_report_preview  Dropbox          .fontconfig       .gnome2          .gvfs            .mozilla              .opera               Skabeloner           .thumbnails                .wapi
.bash_logout   .crash_reportrc        .dropbox         .freemind         .gnome2_private  .hplip           .mozilla-thunderbird  .printer-groups.xml  Skrivebord           .tomboy                    .wine
.bashrc        .dbus                  .dropbox-dist    .gammurc          .gnupg           .ICEauthority    .mplayer              .profile             .Skype               .tomboy.log                .winetrickscache
Billeder       .debtags               .epiphany        .gconf            .googleearth     .icons           .multisync            .pulse               snap.jpg             .update-manager-core       .Xauthority


Så ja. Jeg forstår det ikke. Men det er som om du er inde på noget rigtigt.

[laoshi]

Jeg er desværre nødt til at stå af ind til i morgen eftermiddag - vil jeg tro - men jeg tror at du må lede efter forbindelsen fra dit /home og til /dev og åbenbart også videre ud, selv om jeg ikke lige kan se hvor den skulle være.
Der er godt nok noget at gruble over.
Andre må også meget gerne tænke med!

[zob]

Det er selvfølgelig helt ok. Det er jo trods alt lørdag aften. Tak for hjælpen. Jeg grubler videre...

[laoshi]

Så kan føljetonen fortsætte!
Det viser sig at fejlen ligger et uventet sted, nemlig i brugen af shell-variablen $HOME, som angiver den aktuelle brugers /home. Den var brugt for at det ikke skulle være nødvendigt for andre brugere af scriptet selv at tilføje brugernavnet. Men af uransagelige årsager tager den alt med i backup'en, ikke kun den aktuelle bruger. I den udgave af scriptet som jeg selv anvender havde jeg i stedet for $HOME skrevet stien til mit /home fuldt ud.

Bruger man ikke denne shell-variabel, men i stedet den absolutte sti, så får man kun den aktuelle brugers /home med.
Så erstat $HOME med ~/ (det er: tilde skråstreg) eller med /home/dit_brugernavn/ så får du det ønskede resultat.

Tak fordi du hjalp med til at lokalisere dette problem. Jeg har rettet guiden i overensstemmelse med denne opdagelse, og samtidig benyttet lejligheden til kun at lade backup'en af /usr/ gælde /usr/local/ som er det interessante at gemme. Desuden er der inden backup'en går i gang tilføjet en tømning af papirkurven.

EDIT: som vi fandt ud af er det ikke her fejlen ligger. Den ligger i at vi i stedet for $HOME brugte $Home - så uanset om man bruger $HOME eller ~/ eller /home/dit_brugernavn får man samme resultat: en korrekt fungerende backup

[zob]

Jeg ved ikke hvad det er. Jeg fik den dumme idé at jeg gerne ville være sådan en der laver backups. Men det ser ud til at for sådan en som mig er det farligere at lave backups end at lade være.
Jeg ved ikke helt hvordan eller hvorfor det skete. Men efter endnu et forsøg på at lave backups i formiddags endte jeg med, uden i øvrigt at blive advaret af ubuntu sådan som windows gør, at have lige præcis 0 bytes tilbage på min harddisk. Det resulterede i en del genopretning af bl.a. evolution konti og lignende som forsvandt som dug for solen.
Jeg slettede derefter en masse for at gøre plads igen. Jeg prøvede lige en gang til med en backup og endte i præcis samme situation. Altså måtte jeg finde på mere at slette. Nu kan jeg ikke finde ret meget mere at slette og tør derfor ikke lave backups længere.

Jeg går ud fra at det er fordi den smider det et sted i mit filsystem i stedet for på den eksterne harddisk jeg har kaldt LinuxBackupExt3, på hvilken der da heller ikke er skyggen af backup at spore. (Det var der dog efter de forsøg jeg lavede igår, men i dag med det nye script går det da helt skævt).

Der kom faktisk nogle fejlmeddelelser i terminalen, men jeg glemte at kopiere dem, og jeg kan jo af gode grunde ikke risikere at køre endnu en backup.

Jeg kan ikke finde det sted i filsystemet den skulle have smidt alt det her. Jeg har lavet en diskforbrugsanalyse uden at kunne gennemskue hvor det skulle være blevet af.

Det eneste mistænkelige jeg kan se nu (og som er helt nyt) er at jeg i folderen /media har fået gengangere til alle mine mountede drev. Bl.a. også det drev der efter planen skulle indeholde backup'en, som nu både findes som /media/LinuxBackExt3 og /media/LinuxBackExt3_ (altså med underscore til forskel). Derudover er det kun muligt for mig at tilgå den 'falske' underscore version. Det oprindelige underscore-fri drev kræver at jeg er root (dvs. at jeg skal gksudo nautilus eller noget sudo su i terminalen). Her på dette utilgængelige drev (som user i hvert fald) ligger der faktisk en backup.
Dette gælder i øvrigt også for mine andre mountede drev, hvorfor f.eks. også min musiksamling er raslet ud af rhythmbox, da den er på et mounted drev der nu tilsynelade har fået tilføljet en underscore i sit navn. For alle andre end mit LinuxBackExt3-drev ser det ud til at være underscore versionen der indeholder den ægte vare.

Det er i øvrigt sådan at underscore-drevene nu er de mountede drev (det er jo nyt - eller rettere det er nyt at der overhovedet er underscore-drev). Det kan jeg se når jeg vælger egenskaber. De underscore-fri drev giver oplysning om hvor meget plads der er tilbage på mit filsystem, hvorimod underscore drevene giver mig den gode gamle kage med ledig og brugt plads.

Det virker så kompliceret at jeg overvejer at formattere og begynde på en frisk og så love mig selv aldrig igen at spille smart og forsøge mig med noget så hazarderet som en backup.

Hvad er det for resten meningen der skal stå i den linie der omhandler home-mappen, der har du kaldt stien noget med 'ændret' - skal det være sådan? Eller er det meningen jeg skal ændre det? Og i så tilfælde til hvad?

Den kommando vi sad og knoklede med i går kan også have være forkert fordi jeg brugte $Home og ikke $HOME.

Jeg vil gerne understrege at ingen filer er gået tabt, kun en masse konfiguration.

Tusind tak.

[laoshi]

Øv, øv og tusind øv! for en omgang roderi!

Jeg vil gerne understrege at ingen filer er gået tabt, kun en masse konfiguration.

Det letter min samvittighed en smule - selv om det er ærgerligt og træls at det skulle gå sådan.
Det med diskene lyder som noget roderi. Men du kan koble dem af med

Kode: Vælg alt

sudo umount /media/DISKNAVN

og se om ikke det kan rydde op i tingene. Eller i dit filhånderingsvindue kan du højreklikke på ikonet for disken og vælge afmonter.

Hvad er det for resten meningen der skal stå i den linie der omhandler home-mappen, der har du kaldt stien noget med 'ændret' - skal det være sådan? Eller er det meningen jeg skal ændre det? Og i så tilfælde til hvad?

Nej, du skal ikke ændre noget - som et led i min make-over er det bare navnet på mappen med de ændrede filer (i stedet for at den blev kaldt som brugernavnet). Du kan kalde den hvad du selv vil - det er ikke vigtigt.

Det virker så kompliceret at jeg overvejer at formattere og begynde på en frisk og så love mig selv aldrig igen at spille smart og forsøge mig med noget så hazarderet som en backup.

Det skulle da nødig blive konsekvensen - når du har fået genoprettet dit filsystem, så kunne du prøve med løsning nr. 2: backintime som giver en grafisk overskuelig måde at vælge hvad der skal backes up og hvor det skal gøres.

Den kommando vi sad og knoklede med i går kan også have være forkert fordi jeg brugte $Home og ikke $HOME.

Det er lige præcis det, der er problemet! Lige nu kører jeg en backup med $HOME og den arter sig som den skal.
Jeg kan se på de gamle kommandoer jeg fyrede af i går, og som reproducerede fejlen hos mig, at jeg her er kommet til at bruge $Home - det er en ukendt størrelse som rsync åbenbart ikke kan fortolke og som så ikke standser programmet men får det til at løbe løbsk.

Jeg forstod heller ikke hvorfor det fejlede, og har prøvet at spørge en ekspert om en forklaring (har endnu ikke fået svar - men den forespørgsel kan vist godt annulleres igen)

[zob]

Du skal da i hvert fald ikke have dårlig samvittighed. Det er jo i sidste ende mit ansvar hvad jeg går og laver med min computer og i øvrigt er du jo rigtig flink til at hjælpe. Se bare nu.

Ok. Jeg skal prøve at se på det. Lige nu er jeg på min windows-partition for at se hvordan disk-landskabet tog sig ud herfra. Det ser almindeligt ud, men det føles forkert - jeg er i fjendens territorium. Jeg skal straks tage hjem til ubuntu og se om jeg kan rydde op.

[laoshi]

Så må vi se om ikke det lykkes!
Men hele sagen viser så at man skal passe på med hvad man skriver - og at det er let at komme til at læse det, som man tror der står, og ikke det som der faktisk står.
Det var faktisk først med dit seneste indlæg at jeg rullede tilbage og måtte konstatere at jeg også havde skrevet forkert.
Mærkeligt bare at det får rsync til at løbe grassat i stedet for at melde fejl.