[Ubuntu server] Systeem backup

[EJPostema]

Ik kan bijna niet geloven dat ik hierover geen documentatie heb gevonden, maar ik heb echt een aantal dagen dingen geprobeerd en google gebruikt, maar ik kan niet zo snel vinden wat ik wil.
Ik ben dan ook nog een redelijke n00b in Ubuntu, dus misschien dat ik niet goed zoek.
Ik zit naar rsync oplossingen te zoeken, of is dat helemaal fout...

Goed ik heb dus een tijdje een ubuntu server draaien als downloadbak en backup server.
Het OS draait vanaf een usb stick en alles werkt prima
Omdat ik weet dat usb sticks niet het meest betrouwbare medium zijn om een OS op te draaien wil ik hier graag een back up van.

Wensen
- ik wil een volledige backup van mijn usb stick. Eigenlijk dus een clone. Mocht mijn usb stick kapot gaan kan ik alles copy/pasten naar een nieuwe stick en gaan met die banaan
- backup moet op geslagen worden op mijn windows pc
- automatisch een wekelijkse back up

[MartinMeijerink]

dd

[Hero of Time]

Met Martin. Hij is wat kortaf en geeft geen enkele uitleg over de tool, maar dat is wel het simpelste om te gebruiken. Je maakt een ruwe image van je stick via het dd commando, zet deze op een van je harde schijven en stuurt 'm via SMB of wat dan ook naar de server. Of direct over 't netwerk schrijven naar een SMB share, maar dat is wat meer foutgevoelig.

[MartinMeijerink]

Ok, misschien was ik een beetje kortaf, ik zal mijn betoog van vanmiddag enigszins toelichten:

Je kan het als volgt doen:
Zorg er eerst voor dat je geen regular gebruiker bent, maar root, bij de moderne ubuntu-live cd's gaat dat meestal zo:

sudo su

Nu ben je dus root. Je hoeft vanaf nu nergens meer sudo voor te tikken (tot je weer uitlogt).
Jouw gedeelde map op je windows-pc mounten:

mkdir -p /mnt/mijnsambashare
mount -t cifs -o username=gebruiker,password=wachtwoord //windowspc/windowsshare/ /mnt/mijnsambashare/

Hiermee heb je dus in de map /mnt (die waarschijnlijk al bestond) een map gemaakt met de naam mijnsambashare.
Hierin heb je jouw gedeelde map van je windowspc in gemount.
(Let op, overal forwardslash gebruiken, geen backslash).
In plaats van de naam (windowspc) mag je ook het ip-adres van je windowspc gebruiken, mocht DNS niet goed werken.
FF checken of je iets kan schrijven in jouw windowsshare:

echo test>/mnt/mijnsambashare/test.txt

Kun je deze op je windowspc in notepad o.i.d. lezen, dan werkt de share.
Tijd om de image van je usb-stick ernaartoe te schrijven, dit gaat zo:

dd if=/dev/sda of=/mnt/mijnsambashare/imagevanusbstick.img bs=64k

Typ het niet klakkeloos over, want in jouw geval kan het zijn dat jouw stick niet /dev/sda is, maar misschien wel /dev/sdb of /dev/sdc ofzo.Dit kun je uitzoeken door in te tikken:

fdisk -l

Hiermee krijg je nl. een overzicht van wat er allemaal voor 'schijven' (harddisks, cdromdrives en usbdrives) er in je systeem zitten, en welke identifiers deze hebben. Aan de grootte kun je het makkelijkste zien wat jouw stick is.
Een harddisk heeft (vrijwel altijd) 1 of meerdere partities, een stick vaak ook wel.
/dev/sda is een schijf/stick, /dev/sda1 is partitie 1 van deze schijf/stick, /dev/sda2 partitie 2 enz...

Met dd moet je wel heeeeel goed uitkijken wat je achter 'of=' hebt staan, want wat daarachter staat wordt zonder waarschuwing overschreven ('if' is inputfile, 'of' is outputfile. Ook een stick of een schijf wordt als file gezien, dus oppassen!).
Met bs=64k geef ik overigens aan dat de blockgrootte 64 kilobyte is, dat maakt voor het eindresultaat niks uit, als je bs echter niet opgeeft, wordt een standaard blockgrootte van 512 bytes gebruikt, dit veroorzaakt veel overhead, en daardoor gaat het een stuk langzamer.
Na afloop de share evt. weer unmounten:

umount /mnt/mijnsambashare

Automatisch een wekelijkse backup is heel makkelijk via de crontab te doen, je zet in het bestand /etc/crontab bijvoorbeeld deze regel:

30 23 * * 6 root /usr/local/bin/wekelijksebackup.sh

Hiermee geef je aan dat elke zaterdag (6) om 23:30 uur als root het bestand /usr/local/bin/wekelijksebackup.sh wordt uitgevoerd. * * staat voor datum en maand.
De extensie .sh hoeft niet, maar is voor je eigen duidelijkheid wel handig.
In /usr/local/bin/wekelijksebackup.sh zet je dan vervolgens:

#!/bin/sh
if=/dev/sda of=/mnt/mijnsambashare/imagevanusbstick.img bs=64k

Dit bestand moet je wel even uitvoerbaar maken, dit doe je zo:

chmod +x /usr/local/bin/wekelijksebackup.sh

Om je wekelijkse backupscript handmatig ff te testen kun je deze starten door gewoon in te tikken:

wekelijksebackup.sh

Je kan natuurlijk het mounten van de windows-share ook in dit script verwerken, want nu gaat het script er gewoon vanuit dat de share al gemount is.
Zijn er nog vragen?

[RemcoDelft]

Ik gebruik altijd liever "cat" dan "dd". Veel eenvoudiger, niks blocksize instellen.
Is het een optie om de stick meteen naar een andere stick te kopieren en de netwerk-tussenstap over te slaan?
Dus:
cat /dev/sdx > /dev/sdy
Klaar

Het enige wat evt problemen kan geven (maar dat heb je bij elke andere kopieermethode ook) is dat de stick gemount is, en er dus schrijfacties kunnen plaatsvinden tijdens het kopieren. Je backup is dan meteen corrupt.

[ Voor 4% gewijzigd door RemcoDelft op 14-05-2013 23:12 ]

[Thralas]

De dd-methode levert een unclean, inconsistent snapshot op van je filesystem. Lijkt me inderdaad geen goed idee.

Bovendien is het inefficient (je imaged ook unused space) en problematisch als je je 4 GB image naar een 2 GB stick wilt restoren.

Derhalve is een file-level backup veel logischer. Duplicity (Dejadup), rsync, rdiff-backup - pick any. Enige nadeel daar is dat je een backup van je bootloader dient te maken en 'm zo moet configureren dat het ook nog boot als je fs uuid verandert.

En dat gaat nou misschien net te diep voor TS - maar het zou me niet verbazen als Ubuntu inmiddels een find-Ubuntu-installs-and-fix-bootloader-optie heeft op de installatiemedia.

[Hero of Time]

Thralas schreef op woensdag 15 mei 2013 @ 01:18:
Bovendien is het inefficient (je imaged ook unused space) en problematisch als je je 4 GB image naar een 2 GB stick wilt restoren.

Dat wil je in zo'n geval niet, van je UUID verandert. Als je een dd image maakt, zal deze waarschijnlijk gelijk blijven omdat je ook alle metadata meeneemt.

Derhalve is een file-level backup veel logischer. Duplicity (Dejadup), rsync, rdiff-backup - pick any. Enige nadeel daar is dat je een backup van je bootloader dient te maken en 'm zo moet configureren dat het ook nog boot als je fs uuid verandert.

Dat kan je doen door met dev nodes te gaan werken, maar kan weer zo z'n problemen geven tijdens boot (je BIOS ziet je HDD eerder dan je USB stick, stick is geen /dev/sda meer). Maar als je een backup moet terugzetten heb je toch downtime, wat is die ene minuut meer of minder nou om even de UUID te zoeken en aan te passen?

En dat gaat nou misschien net te diep voor TS - maar het zou me niet verbazen als Ubuntu inmiddels een find-Ubuntu-installs-and-fix-bootloader-optie heeft op de installatiemedia.

Zoiets heet install-grub en kan je vanaf elke installatiemedia uitvoeren. Omdat je config er al is, net als alle andere bestanden, heb je alleen een chroot nodig en voer je de install-grub uit om 'm naar MBR te schrijven. Dus eenmaal je stick naar een andere te hebben gekloond via file copy, is 't niets anders dan dit uitvoeren, uitgaande dat sdb je nieuwe stick is:

mount --bind /proc /mnt/stick2/proc/
mount --bind /dev /mnt/stick2/dev/
chroot /mnt/stick2
install-grub /dev/sdb

[EJPostema]

MartinMeijerink schreef op dinsdag 14 mei 2013 @ 17:53:
dd

Dank voor je latere uitgebreide uitleg. Ik zal me er eens in verdiepen.
Dat het misschien iets minder efficiënt is en wat langer duurt maakt me niet uit. Het gaat erom dat ik een goede back up heb

[Thralas]

Hero of Time schreef op woensdag 15 mei 2013 @ 08:47:
Dat kan je doen door met dev nodes te gaan werken, maar kan weer zo z'n problemen geven tijdens boot (je BIOS ziet je HDD eerder dan je USB stick, stick is geen /dev/sda meer). Maar als je een backup moet terugzetten heb je toch downtime, wat is die ene minuut meer of minder nou om even de UUID te zoeken en aan te passen?

Op disk name booten is inderdaad ook niet echt praktisch, maar grub2 kan ook nog op basis van filesystem labels of file presence booten. Dat is beide redelijk 'portable'.

Zoiets heet install-grub en kan je vanaf elke installatiemedia uitvoeren. Omdat je config er al is, net als alle andere bestanden, heb je alleen een chroot nodig en voer je de install-grub uit om 'm naar MBR te schrijven. Dus eenmaal je stick naar een andere te hebben gekloond via file copy, is 't niets anders dan dit uitvoeren, uitgaande dat sdb je nieuwe stick is:

mount --bind /proc /mnt/stick2/proc/
mount --bind /dev /mnt/stick2/dev/
chroot /mnt/stick2
install-grub /dev/sdb

Klopt, maar aangezien TS aangaf onervaren te zijn noemde ik de automagische repairoptie. Zoiets dus. Maar als je 't handmatig kunt, kun je het desgewenst met een willekeurige LiveCD

[EJPostema]

MartinMeijerink schreef op dinsdag 14 mei 2013 @ 23:08:

Zijn er nog vragen?

Volgens mij heb ik het voorelkaar.
De server is nog bezig met het maken van een image, maar volgens mij gaat alles goed.

Ik moest alleen mijn ip adres gebruiken (pc naam pakt die niet). Ik heb zo'n vermoeden dat dit problemen gaat opleveren met het script. Mijn pc zet ik namelijk uit en krijgt dan een nieuw ip.
Hier moet ik dus even naar kijken. Vooralsnog dus een handmatige back-up. iig bedankt voor de hulp

Dit weekend maar eens testen of het goed is gegaan

[jnr24]

Simpel is vaak goed, maar niet altijd.

dd lijkt me een prima oplossing, eenvoudig, je weet wat je hebt, wel even goed testen in een aannemelijk scenario..

Let echter ook op je versies, als je altijd "backup_image" overschrijft kan het gebeuren dat:

1. de boel crash tijdens de backup, weg backup
2. er sluipt iets in je backup dat je pas een week later merkt (corrupte bestanden, slechte update)
3. je maakt zelf een fout tijdens restore waardoor image ineens weg is
4. er gaat iets kapot aan je hardware waardoor de usb stick niet meer boot vanwege drivers

punt 1-3: Een weekdag tellertje toevoegen aan de naam kan al een oplossing zijn. Qua diskruimte is rsync/rdiff-backup dan een handig alternatief of parallelsysteem (voor het terugvinden van losse configuratiebestanden bv)

punt 4: Ik kan aanraden om regelmatig een (virtueel) systeem (geautomatiseerd) te installeren (bijvoorbeeld unattented/kickstart installatie vanaf het netwerk).

Mocht er een keer iets mis gaan dan koop je nieuwe hardware, start de automatische installatie, kopieer eventueel nog handmatig een tiental bestanden en/of data (wel backup van maken!). Je voorkomt de situatie hoe je X jaar geleden ook weer die lastige driver had geinstalleerd, die rare firewallsettings goed had gekregen enzovoorts.

[ Voor 5% gewijzigd door jnr24 op 24-05-2013 00:06 ]

[EJPostema]

Ja, dat had ik ook al bedacht. Wil minimaal twee back ups hebben idd.

Zal de backup zo af en toe testen met de reserve stick die ik hier heb liggen

[gertvdijk]

Een wat mij betreft underrated backupmethode is voor Linuxsystemen is het aloude 'dump' (op Ubuntu gelijknamige pakketnaam).

Het is uitsluitend voor ext2/ext3/ext4, maar is altijd met behoud van *alle* metadata en voorziet in incrementele backups ook.