Ämne: Bättre backup-program i Ubuntu och extern HDD?

[bopakoster]

Hej,
jag har kört med Dejàdup som backup-program mot min löstagbara USB 2.0-HDD (HP) men programmet slutade att fungera ifjol med att säga att den inte grejar in/ut på den längre. HDDn är halvfull så programmet kanske inte får plats med mer än 50% för att klara trafiken? (tänker att det kanska behövs temporärt ledigt utrymme lika stort som backupen....)

-Har någon ett bättre programförslag eller åtgärd för att få det att funka?

-Lurar på att skaffa en ny extern HDD, förslag på något lämpligt? (minst 1-2TB)
Eller finns det tillförlitliga SSD till bra pris?

[xxargs]

Har du in/ut fel så brukar det ofta bero på någon HW-beroende grej.

Skulle det ta slut pga. temporärfiler ätit upp utrymmet så hade du förmodligen fått ett annan typ av fel.

Jag skulle omedelbart flytta innehållet till en annan disk (stora diskar är inte speciellt dyra - dock SSD är fortfarande dyra och inte alls i den önskade storleken av 1-2 TB som du siktade på, och kör du USB2 har du heller ingen nytta av SSD-disken snabbhet - en vanlig ordinär disk med skivor är 5 ggr snabbare (100 - 150 MB/s)  än vad USB2 klarar att transportera (20 MB/s - ibland lite över 30 MB/s om det är stora sammanhängande filblock som ligger sekventiellt)  skall du ha fart så är det USB3 alternativt Esata om din dator hantera detta då du med dessa kan komma upp i diskarna hastighet och kanske får en vinst i hastighet med SSD.

dock med backup brukar man inte sikta på snabbast möjliga snabbhet - bara den har resonabel hastighet (ca 100 MB/s med USB3 och vanliga diskar med skivor) och  stor storlek på HD så att man lagra mycket eller i många generationer.

Skall man var a riktigt noga så skall du alltid köra mot två olika backdiskar - även en backupdisk kan gå sönder...

för att se om den gamla disken tänkas ha problem:

Provläs hela disken med 'dd' och se om du råkar på någon sektorfel

'dd if=/dev/sdx of=/dev/null bs=1024k' där sdx är den råa devicen för disken och brukar kallas typisk 'sdc'  eller liknande  om datorn har en HD och en CD/DVD-läsare ansluten. antal block i MB som rapporteras bör stämma med hela disken storlek, dock det här kommer att ta tid om disken är 2T och det går igenom en USB2:anslutning - räkna med minst ett dygn om det tuggar på 20 MB/s

provskriv kvarvarande utrymmet med 'dd' med datakällan /dev/zero till en fil på disken och se om du kan fylla upp hela disken den vägen utan fel förutom att disken blir full.

se till att disken är mountad och filsystemet bruka hittas i /media/filsystemnamn  eller /media/user/filsystemnamn

'dd if=/dev/zero of=/media/där_usb_disken_är_mountad/zerofiles bs=1024k'; filen zerofile skapas och fylls med nollor tills disken är full.

det här kan också ta lång tid och beroende på hur stor och hur fylld disken är.

Stämmer antalet block med antal MB som fanns kvar innan skrivningen utan in/ut-fel så är disken förmodligen frisk.

Sedan tar du bort 'zerofiles' så får du tillbaka utrymmet på disken igen.

Är du rädd om datat så kopierar du backuppfilerna innan till en annan disk.

---

Andra saker att kolla på är problem med rättigheter om du inte kör som root - dock bör du inte få in/ut-fel av detta.


Har kört för lite 'deja dup' för att veta hur den fungerar ännu, dock verkar den arbeta med en krypterade tar-filer och om jag mins rätt var dom ganska små men många vilket innebär att den inte använder några stora temporärfiler samt använder rsync för inkrementell backup, vilket innebär att det är bara diff-skillnaderna på det som ändrats i filerna som sparas och inte hela filen igen var gång något ändrats i filen - rsync jobbade ju med att så lite som möjligt skulle skickas över kommunikationslänken och den egenskapen används även här för att arkivet skall växa så lite som möjligt 

En variant jag provat som alternativ är rdiff-backup (i terminalmode)  som också använder rsync. denna ger en diskimage på senaste versionen alltid åtkomlig medans tidigare generationer blir diff-filer, komprimeras och sparas undan. - detta innebär också att gamla generationer kan tas bort utan att behöva göra en ny full backup då den äldre generationen alltid är en diff till den yngre generationer som i sin tur är den diff till den ännu yngre generationen hela kedjan till den nyaste backuppen som alltid är fulla filen.  därför kan man alltid ta bort den äldsta generationen utan att det pajar diff-kedjan till senaste backuppen.

 



   

[Volvo245GLT]

Var extremt försiktig med DD ("disk destroyer"...) bara. Det ställer inga onödiga frågor och kan lätt ställa till med en hel del oreda om man råkar ge fel kommando. 

Jag brukar bara ta en kopia på /home och sen göra det hela lite mer lätthanterligt med valfri arkivhanterare.
Har varken någon speciell programvara eller conf-filer som kräver massa jobb att återställa, så det duger gott åt mig.

Backupen sparas sen på två olika diskar, en formaterad till FAT32 för ev. åtkomst i Windows och den andra till EXT4.
Mest som bonus åker en del av datan även åker upp i "molnet".
Dell hade någon kampanj på Box.com rätt nyligen där man fick 50 GB gratis, och liknande erbjudanden dyker upp hela tiden.

[bopakoster]

Tack för era uttömmande svar xxargs och Volvo245GT!  ,

Jag frågade om SSD mest med tanke på hållbarhet mer än snabbhet, inga mekaniska delar borde hålla bättre?

Ska köpa ny extra hårdisk imorgon först(tips på bra märke?) och lägga över /home på den innan jag börjar meka med den gamla enligt ditt förslag xxargs. Vet att det är lite fel på den får en notis om det varje gång vid uppstart av Ubuntun. Hinner dock inte med att notera var. Har haft det beskedet sen lång tid tillbaka, långt innan Dejàdup fallerade.

Vad och hur menar du med valfri arkivhanterare Volvo245GT?

[xxargs]

Mycket riktigt är 'dd' ett 'skarpt' verktyg - ungefär som mycket vass skapell eller kniv , i varsam hand kan den läka och hjälpa - i okunniga händer kan den slakta.

Även om det  oftast numera  är inlindad i alias med 'rm -i' i default-shellet som ger en extra chans att ångra sig, så var 'rm -r ' känd för att kunna vara förödande

tex. 'rm -r * .o' när du skall ta bort en massa xxx.o- filer (tex. efter kompilering etc.)  - det kan bli väldigt mycket plats på hårddisken efter detta pga. ett extra mellanslag på fel ställe...

amerikanare på US-tangentbord råkar för eller senare ut för 'rm -r *>o' istället för 'rm -r *.o' då > sitter på samma knapp som '.' och släpper man inte shift tillräckligt snabbt fter '*' och trycker enter innan man läst vad man skrivit så får man en 0-bytes fil som heter 'o' och väldigt gott om plats på disken för denna fil.

 ---

Hårddiskar är ungefär som glödlampor  - man vet att dom går sönder förr eller senare och man vet ungefär _hur_ de går sönder med oftast chans att rädda data innan det är försent.

SSD är ungefär som energisparlampor där vet man inte riktigt hur de går sönder och man vet inte om huset står kvar eller brunnit ned efter när dom har gått sönder, och ofta har man inte en chans att få ut något data alls när de börja vägra samarbete och det helt utan förvarning.

Skall man lagra stora datamängder så är SSD fortfarande för dyrt om det inte skall vara i speciella sammanhang som laptop eller liknande där det är hög risk att åka i backen och/eller jaga prestanda. långtidslagring är också osäker då de lagrar data med flera olika spänningsnivåer per minnescell (tex USB-minnen)  - det är bara de med extrema och dyra SSD som lagrar enkelnivå-celler i applikationer som måste tåla väldigt många omskrivningar som HD med kombinerad SSD och traditionell disk (för att få upp snabbheten främst) och dessa brukar heller inte vara så stora i minnesmängd.   

Och fortfarande - har du inte samma fil lagrad på minst två olika fysiska platser så är det en obackuppad fil som kan förloras när enheten den lagras på går sönder.

Själv har jag köpt en 4-disk NAS som med RAID-konfiguration gör att den tål en diskhaveri utan att förlora data (nu med 2T -4T diskar så är det så mycket man förlorar om en sådan går sönder) - dock skyddar den fortfarande inte för 'rm -r * .o' misstag eller direkta åsknedslag, brand  eller stöld, så en fungerande backupprutin mot ytterligare externa backuppdiskar (som lagras på annan ställe mellan backuptillfällena) måste man fortfarande ha - dvs. filen finns alltid på minst två platser även när den inte är lagrad på sin laptop längre utan bara i NAS:en

[Volvo245GLT]

Vad och hur menar du med valfri arkivhanterare Volvo245GT?

Zip, rar, tar o.s.v.. Ett program som komprimerar och bakar samman datan till en eller flera filer helt enkelt.
Antingen jobbar man grafiskt eller via kommandoraden, alldeles beroende på vilket man föredrar.
Många hanterare kan uppdatera arkivet man skapade med det som ändrats sen sist, ungefär som ett mer renodlat backupprogram.

SSD i all ära, men för backup är vanliga mekaniska diskar oslagbara. De rymmer mycket till ett lågt pris, och hanterar man dem bara varligt så får man ofta en förvarning om haveriet innan det inträffar.
Onormala ljud, skadade sektorer... Det inbyggda systemet ("smart") brukar också kunna säga till i tid.
Och i absolut sämsta fall så finns det firmor som specialliserat sig på att plocka ur datan ur skadade hårddiskar. T.ex. sådana från en nerbrunnen byggnad eller som legat på havsbotten i några år... Men det kostar ju därefter också.

När jag pluggar in en av mina diskar, en gammal Samsung 80 GB (och en av de första som kom med S-ATA), så varnas det direkt om att den mår dåligt och att haveriet är nära förestående.
Disken i fråga har dock fungerat i flera år trots detta och överlevt en del ovarsam hantering.. Och den används självklart inte till att lagra något viktigt.
Hade den varit en MFM/RLL så hade kanske en lågnivåformatering hade varit något att testa... 

På tal om det så satte jag nyligen fart på en 31 MB stor/enorm Seagate ST 4038 som tidigare satt i en IBM AT från 1986.
Disken i fråga hade inte varit använd sen 1995 av filerna på den att döma, men MS DOS 6.0 som den tydligen försetts med bootade upp som vanligt!
Tänker vänta tills disken med tillhörande fullängds kontrollerkort fyller 30 år nu och prova igen.

Tveksamt om dagens diskar, såväl mekaniska som SSD kommer kunna bevara sin data efter såpass lång tid.

[xxargs]

Man bör använda arkiverare med en filformat som går att hantera även om den skulle fattas någon del pga. ej läsbar sektor, och då är det 'tar' som gäller - där har man distruberat filnamn, filrättighet och filpath tillsammans med själva filen - 'tar' är byggd för att klara att ett magnetband går av  eller blir oläslig en bit och det är bara den biten som skadas/oläsbar som förloras - inte hela arkivet som annars gäller för nästan alla andra arkiv-former som zip, rar etc. där om man förlorar första biten så är hela arkivet oläsligt.

Skall man vara riktigt noga så skall man gzippa varje individuell fil och sedan av filerna göra en tar-arkiv i okomprimerad format. För kör man tar gzippat (*.tgz) på hela arkivet så lider den av samma bekymmer som zip och rar att den inte går att packa upp vidare efter där skadan inträffade pga att det är komprimerat och informationen som fanns i den förstörda området behövs för att packa upp vidare.

Kom ihåg det är inte bara band som kan gå av eller bli knycklade en bit, om det lagras på CD/DVD så kan det bli stycken som inte går att läsa pga. repa eller tidens tand, mer sällsynt men förekommer även på HD med oläsbara sektorer i storlek från 4 kB till 16 kB beroende på hur det lagras internt.
 
Det är också av den orsaken man alltid skall ha minst två exemplar av sina viktiga filer på olika medium - helst av olika slag så att dessa inte pajar samtidigt pga. en mindre bra batch DVD-R skivor där alla exemplar blir oläsliga ungefär samtidigt inom några månader - när det gäller HD av olika tillverkare så man inte råkar ut för IBM:s click of dead, eller maxtors för klena motorstyrningar som brinner efter något antal tusen timmar drift när man startar disken igen - i allafall skall det inte ske på samma gång...
 

[purjo__]

Kommandot badblocks är bättre att testa disken med än dd. Sen kan man se ganska mycket i kernelloggen med kommandot dmesg, dock bör man kanske ha ett tränat öga för att se vad som är fel och inte... Kör det direkt efter att backupprogrammet har get ett felmeddelande så borde du kunna se om det är diskfel.

[shelter]

Klipp ut det som står i dmesg angående disken och visa här så bör vi kanske kunnna avgöra vad som är fel även om det inte alltid är så lätt.

Jag har haft IO fel på diskar, i ett fall visade det sig i slutänden vara ett dåligt grafikkort som ställde till det. Det var tydligen nåt sammanhang mellan AGP-porten och SATA kontrollern, bytte grafikkort och då funkade allt igen.

[redholm]

Jag gillar inte backup program för man måste testa restore funktionen och jag är för lat för det.
Jag använder sync program och sedan snaphots på sync kopian.

rsync är bra på sync och rsnaphot är bra på snapshots.  Jag har sync kopian på en disk och snaphots på en annan disk.
rsync och rsnapshot finns till Ubuntu.

[xxargs]

Rsync och rsnapshot är också backupprogramvaror i någon form - och skall man kolla ordentligt så måste man fortfarande prova att göra en 'recovery' dvs. man stoppa en ny tom disk i datorn med kanske större storlek och se hur fort och hur enkelt eller omständigt det är innan datorn botar upp igen precis som innan...

hmm - hanterar rsync och rsnapshot inkrementell backup ?? - det händer att man kanske vill ta tillbaka något 'oviktigt' som man tog bort för flera månader eller en förlust eller skada på en fil som inte märks förrän långt senare.

rdiff-backup är egentligen mera en rsync med inkrementella generationer mellan gångerna.

[bopakoster]

Själv har jag köpt en 4-disk NAS som med RAID-konfiguration gör att den tål en diskhaveri utan att förlora data (nu med 2T -4T diskar så är det så mycket man förlorar om en sådan går sönder) - dock skyddar den fortfarande inte för 'rm -r * .o' misstag eller direkta åsknedslag, brand  eller stöld, så en fungerande backupprutin mot ytterligare externa backuppdiskar (som lagras på annan ställe mellan backuptillfällena) måste man fortfarande ha - dvs. filen finns alltid på minst två platser även när den inte är lagrad på sin laptop längre utan bara i NAS:en

Jaha. Nu har jag skaffat en 2-disks NAS. D-Link DNS320L och 2st WD Red (1TB vardera) NASHard drive.
Hur tycker du jag ska sätta/koppla upp den?
Är en gammal man som gör så gott han kan så jag fattar inte så mycket facksnack, men det går ju att "fråga annars får man inga svar"   
Har ett nätverk hemma med en gammal D-link DI-514 router, som sänder på ethernet(mha Devolo-dosor över elnätet) och Wifi. Har på nätet en gammal Hp dator med dualboot Win XP och Ubuntu 12.04 och en laptop med Win Vista Home och skrivare, scanners mm.
Vill alltså lägga dubbla backuper nu på NASen från båda datorerna och kanske fler i framtiden.
Det är väl mest mitt bildarkiv, som jag vill säkra, dels det som man skapar nu med digitala kameror och dels det som jag håller på och digitalisera ur det analoga arkivet, Dior, foton och film. Men förstås även vanliga dator"dokument".

[redholm]

Xxargs
rsync ser till att sync kopian är identisk med originalet.  Enkelt att testa med olika program.  Rsync flyttar endast förändringar om en stor fil har en liten förändring flyttas endast förändringen.
Om du tar bort en fil så kommer filen också att tas bort from sync kopian. Det är därför man kombinerar rsync med rsnapshot so man har gamla kopior.
rdiff gör ungefär samma sak i ett program men svårare att kontrollera gamla filer man måste testa restore funktionen.  Med rsync rsnapshot behöver jag inte testa restore jag kan läsa /jämföra filer direkt.

Bopakloster
På disk 1 lägger du filer som endast finns på NASen och backup av varje dator
På disk 2 lägger du backup av disk1.
Nu finns filer på minst två diskar vissa filer finns på tre diskar.
Försök att få backup/sync att ske automatiskt annars glömmer man bort och det blir inte gjort.

[purjo__]

Enklast är väl att spegla diskarna i NAS'en. Då gör det inget om en disk går sönder så länge man upptäcker det i tid.

[xxargs]

redholm:

Men du får ingen generationshantering (inkrementell...) av backupper utan bara en aktuell spegelbild ??
dvs. kan du få fram en fil som fanns för 6 månader sedan men togs bort för 3 månader sedan med ditt upplägg??

rdiff-backupp kör också med rsync-teknik och bara flyttar över dom bitar som förändrats (och gör en gömd, tidsstämplad backup av det gamla stycket i filen innan delarna byttes ut senaste version - och kan göra processen baklänges om man vill få fram en tidigare version av filen ifråga av någon orsak.   

---

bopakoster:

Även om man har en NAS så måste man då och då göra en backup på denna  då även om du kör speglat i en NAS (och vid flera diskar än 2  i raid5) och tål en diskkrash så skyddar det inte mot mänskliga misstag som tidigare nämnt 'rm -r * .o' när man menar 'rm -r *.o' - för om man är root i linux och dessutom i filsystemsroten på disken så ryker hela diskinnehållet på väldigt kort tid.

Sedan kan man alltid tjata om brandrisk och stöldrisk etc. men sådant svider inte tillräckligt förrän man faktiskt har blivit av med precis allt man hade vid en sådan händelse, så egentligen hjälper det inte att tjata om det...