Bash script voor image backup naar ftp

[Rgerr]

Hallo allemaal,

Ik probeer een bash scriptje te schrijven om mijn Ubuntu server te backuppen naar een .iso bestand en te uploaden via FTP naar mijn NAS op een ander systeem.

Daarvoor moet ik een aantal commando’s uitvoeren, en heb ik hier in een bash script gezet:

code:

#!/bin/bash
ftp 192.168.x.xx
- hier loop ik al vast, ik moet inloggen maar krijg dat niet via script voor elkaar. Ftp user:pass@ip werkt bijvoorbeeld ook niet.
cd /path/naar/backup/locatie/
put "|sudo dd if=/dev/sda" Ubuntu-backup.iso

Tips? Tricks? Tuts? Alle hulp is welkom.

[MAX3400]

Zoek eens op "ftp netrc" en mogelijk kan je dan al een stukje verder komen?

Andersom; je zou natuurlijk ook je NAS-share tijdelijk kunnen mounten, je backup laten maken, en dan weer dismounten.

/edit: even andere observatie; weet je zeker dat je dd-commando goed verloopt? Niet dat er intern een loop ontstaat omdat je met dd een temp-file staat aanpast en die ook naar de ISO trapt? Ik zou ook nog even kijken naar de overige switches voor dd; sowieso even nadenken over je blocksize en het omzeilen van read-errors

[ Voor 45% gewijzigd door MAX3400 op 26-12-2018 12:41 ]

[DukeBox]

Daarnaast is dat met scp nog veel makkelijker te doen. scp file.ext user@host:\path\..

[mkroes]

Wat standaard commando's:

code:

ftp
open (ftp-site of ip-adres)
user [gebruikersnaam] [wachtwoord]
lcd /directory  (wijzigen van map op ftp locatie)
cd /directory  (wijzigen van map op pc)
put whateverfileyouwant.txt
bye

Verder: wat @MAX3400 ook al aangeeft, is het mischien gemakkelijker om je NAS tijdelijk te mounten.

[Rgerr]

code:

#!/bin/sh
TIMESTAMP=`/bin/date +%Y-%m-%d-%H%M`
ftp -n 192.168.x.xx << EOF 
quote USER user
quote PASS pass
cd /path/
put "|sudo dd if=/dev/sda" Ubuntu_$TIMESTAMP.iso 
quit
EOF

Ben al iets verder, hiermee wordt in elk geval netjes een .iso gemaakt. Zie alleen geen progressie of foutmeldingen, maar daar valt vast iets voor te maken. Verder heb ik geen idee hoe het zit met mounten van de NAS of andere mogelijkheden. Dit is zo’n beetje mijn eerste bash script, na zelf wat scripts te hebben aangepast.

[ Voor 198% gewijzigd door Rgerr op 26-12-2018 13:02 ]

[mkroes]

Waarom je complete drive backuppen?
Is het niet gemakkelijker om alleen bepaalde folders mee te nemen? /home /etc enz..?

[Rgerr]

mkroes schreef op woensdag 26 december 2018 @ 13:01:
Waarom je complete drive backuppen?
Is het niet gemakkelijker om alleen bepaalde folders mee te nemen? /home /etc enz..?

Dat lijkt mij handiger zodat ik na een middag klungelen eenvoudig een image kan terug zetten.

[mkroes]

Kan je dan niet beter overstappen op virtualisatie of een filesystem wat werkt met snapshots?

[synoniem]

Wat ook prima werkt is rclone dan kopieer je alleen de bestanden die gewijzigd zijn ten opzichte van de vorige keer.

[MAX3400]

@Rgerr klungelen is 1, documenteren van je geklungel is eigenlijk al voor stap 1. Op zich goed bezig maar had je al een restore uitgevoerd van je ISO als je je "running machine" hebt verziekt?

@mkroes ja, dat lijkt me inderdaad een slimmer idee. Ongetwijfeld kost het geld (resources) om een beetje te virtualiseren maar afhankelijk van de huidige infra, is virtualisatie een leuke manier om verder in te gaan.

[Rgerr]

Het ding is, dat ik er ook Domoticz en Homebridge op heb draaien. Als ik het systeem om zeep help en geen image terug zet, kan ik die zaken opnieuw instellen op mijn iPad e.d. voor de automatiseringen. Als ik wel een image terugzet heb ik dat probleem niet, vandaar de keuze voor en volledige image. Maar als ik eenvoudiger dan een bash script zo’n image kan draaien en uploaden... Kan dat met de eerder genoemde opties?

[H!GHGuY]

Het tooltje dat je zoekt heet "expect". Daarmee kan je stdin/stdout van een programma scripten.

Daarnaast wil je even kijken naar lftp en ncftp, die hebben mogelijkheden om een directory te mirroren.

Een andere suggestie om btrfs te gebruiken, die heeft een btrfs-send command waarmee je incrementele snapshots kan opsturen naar ergens anders. Sowieso, zouden die snapshots handig kunnen zijn voor je, om gewoon rollback te doen wanneer nodig.

[ Voor 37% gewijzigd door H!GHGuY op 26-12-2018 13:37 ]

[Rgerr]

H!GHGuY schreef op woensdag 26 december 2018 @ 13:33:
Het tooltje dat je zoekt heet "expect". Daarmee kan je stdin/stdout van een programma scripten.

Daarnaast wil je even kijken naar lftp en ncftp, die hebben mogelijkheden om een directory te mirroren.

Een andere suggestie om btrfs te gebruiken, die heeft een btrfs-send command waarmee je incrementele snapshots kan opsturen naar ergens anders. Sowieso, zouden die snapshots handig kunnen zijn voor je, om gewoon rollback te doen wanneer nodig.

Heb eens gekeken naar btrfs, zie alleen nog niet helemaal hoe het in zijn werk gaat. Adhv een snapshot kun je een image genereren van je systeem?

[mkroes]

Indien je tijdens de installatie van ubuntu een lvm aan hebt gemaakt, kun je van hieruit ook snapshots maken.
Hier wat info: https://www.tutonics.com/...part-2-snapshots.html?m=1
Of hier:
https://askubuntu.com/que...p-restore-point-in-ubuntu

[vso]

Rgerr schreef op woensdag 26 december 2018 @ 13:25:
ik er ook Domoticz en Homebridge op heb draaien.

ik zou bij die pakketten die je noemt eens kijken wat hun "adviseren" aan backup mogelijkheden ..

Waarom backup maken van wat je kan downloaden ?
maar een iso draaien is op zich niet erg. zeker als het werkt.

je kan ook voor versie beheer gaan, usb stick eraan hangen en daarop de gewijzigde bestanden laten zetten.

Verdiep je in iedergeval eens beter in de backup mogelijkheden.

[Rgerr]

mkroes schreef op woensdag 26 december 2018 @ 14:41:
Indien je tijdens de installatie van ubuntu een lvm aan hebt gemaakt, kun je van hieruit ook snapshots maken.
Hier wat info: https://www.tutonics.com/...part-2-snapshots.html?m=1
Of hier:
https://askubuntu.com/que...p-restore-point-in-ubuntu

Niet gedaan.

vso schreef op woensdag 26 december 2018 @ 14:43:
[...]

ik zou bij die pakketten die je noemt eens kijken wat hun "adviseren" aan backup mogelijkheden ..

Waarom backup maken van wat je kan downloaden ?
maar een iso draaien is op zich niet erg. zeker als het werkt.

je kan ook voor versie beheer gaan, usb stick eraan hangen en daarop de gewijzigde bestanden laten zetten.

Verdiep je in iedergeval eens beter in de backup mogelijkheden.

Daar draait ik al aparte backups van, Domoticz de database en Homebridge config bestand. Beide worden ook geüpload naar NAS via bash. Werkt prima hoor, maar het terugzetten van zo’n backup geeft als probleem dat ik de automatiseringen op HomeKit opnieuw dien in te stellen, doordat iCloud een ‘nieuwe’ hub ziet. Gezien ik ondertussen al vrij complexe (lees: tijdrovende) automatiseringen heb ingesteld, is dat onwenselijk. Dus mijn wens is eigenlijk een volledige image/.iso kunnen draaien van de os drive en die uploaden via ftp (of ander programma).

[vso]

[b]Rgerr schreef op woensdag 26 december 2018 @ 14:55:
Daar draait ik al aparte backups van, Domoticz de database en Homebridge config bestand. Beide worden ook geüpload naar NAS via bash. Werkt prima hoor, maar het terugzetten van zo’n backup geeft als probleem dat ik de automatiseringen op HomeKit opnieuw dien in te stellen, doordat iCloud een ‘nieuwe’ hub ziet. Gezien ik ondertussen al vrij complexe (lees: tijdrovende) automatiseringen heb ingesteld, is dat onwenselijk. Dus mijn wens is eigenlijk een volledige image/.iso kunnen draaien van de os drive en die uploaden via ftp (of ander programma).

kan je niet uitzoeken hoe je voorkomt dat hij het als nieuwe hub ziet ? , je hebt de meest simple oplossing al (iso) maar een nettere manier is wellicht wenselijk ..

[CurlyMo]

Rgerr schreef op woensdag 26 december 2018 @ 14:31:
[...]
Heb eens gekeken naar btrfs, zie alleen nog niet helemaal hoe het in zijn werk gaat. Adhv een snapshot kun je een image genereren van je systeem?

Ja, kijk ook naar ZFS. Dat is nog veel makkelijker en stabieler dat BTRFS is op dit moment.

[Rgerr]

vso schreef op woensdag 26 december 2018 @ 15:03:
[...]

kan je niet uitzoeken hoe je voorkomt dat hij het als nieuwe hub ziet ? , je hebt de meest simple oplossing al (iso) maar een nettere manier is wellicht wenselijk ..

De mogelijkheid om een rollback te doen lijkt mij ook een mooie oplossing, net even geprobeerd via het bash scriptje een backup te maken, maar dat duurt vrij lang. Logisch ook, het is een 120gb ssd. De wens is er om er iets kleiners van te maken (partitie of kleinere ssd), maar eerst de mogelijkheden voor volledige backup verkennen en proberen.

Is er binnen Ubuntu zelf een oplossing om snapshots te maken en aan de hand daar van je systeem terug te zetten?

Heb al eens gekeken naar waarom iCloud een nieuwe hub ziet en niet de ‘oude’, daar is geen consensus over en Apple wil (natuurlijk) geen fatsoenlijk antwoord geven.

[vso]

Rgerr schreef op woensdag 26 december 2018 @ 15:08:
Heb al eens gekeken naar waarom iCloud een nieuwe hub ziet en niet de ‘oude’, daar is geen consensus over en Apple wil (natuurlijk) geen fatsoenlijk antwoord geven.

zal wel iets te maken hebben met een certificaat/code die ergens op je machine opgeslagen word/is
geen code bij het aanmelden = nieuw dus krijg je een andere toegewezen. ..

De mogelijkheid om een rollback te doen lijkt mij ook een mooie oplossing, net even geprobeerd via het bash scriptje een backup te maken, maar dat duurt vrij lang. Logisch ook, het is een 120gb ssd. De wens is er om er iets kleiners van te maken (partitie of kleinere ssd), maar eerst de mogelijkheden voor volledige backup verkennen en proberen.

Is er binnen Ubuntu zelf een oplossing om snapshots te maken en aan de hand daar van je systeem terug te zetten?

In principe sla je de instellingen op in /etc/<whatever> of bij slecht(ere) in /share/usr/local/<software>
en soms ook nog in /var/<database> of /home/<bla>

Snapshot klinkt leuk maar databases vinden dit soms niet erg tof en gaan dan dood, en bijkomend nadeel is dat ALLES terug gezet word naar die datum/tijd en als jij 2 of 20 dingen gewijzigd hebt .. je weer terug bij af bent..

Met versie beheer, word alle wijzigingen opgeslagen (is wel meer configuratie) maar je kan selectiever terug zetten.

Combinatie van deze 2 is onder windows bekend als "previous versions" en ben je in staat om de snapshot te "mounten" en kan je dus terug zoeken in "backups" ...


Als je weet waar in iedergeval de meuk word opgeslagen kan je deze ook (symlink ) in /dev/sdb maar dit betekend dat je tijdens de installatie wel rekening moet houden met het aanmaken + voorbereiden voordat je de daadwerkelijke installatie v.d benodigde software doet.


120Gb is wel erg veel .. ik zou dit meer onderverdelen in partities

[Rgerr]

vso schreef op woensdag 26 december 2018 @ 15:31:
[...]
zal wel iets te maken hebben met een certificaat/code die ergens op je machine opgeslagen word/is
geen code bij het aanmelden = nieuw dus krijg je een andere toegewezen. ..


[...]

In principe sla je de instellingen op in /etc/<whatever> of bij slecht(ere) in /share/usr/local/<software>
en soms ook nog in /var/<database> of /home/<bla>

Snapshot klinkt leuk maar databases vinden dit soms niet erg tof en gaan dan dood, en bijkomend nadeel is dat ALLES terug gezet word naar die datum/tijd en als jij 2 of 20 dingen gewijzigd hebt .. je weer terug bij af bent..

Met versie beheer, word alle wijzigingen opgeslagen (is wel meer configuratie) maar je kan selectiever terug zetten.

Combinatie van deze 2 is onder windows bekend als "previous versions" en ben je in staat om de snapshot te "mounten" en kan je dus terug zoeken in "backups" ...


Als je weet waar in iedergeval de meuk word opgeslagen kan je deze ook (symlink ) in /dev/sdb maar dit betekend dat je tijdens de installatie wel rekening moet houden met het aanmaken + voorbereiden voordat je de daadwerkelijke installatie v.d benodigde software doet.


120Gb is wel erg veel .. ik zou dit meer onderverdelen in partities

Dat laatste, de combinatie, klinkt erg goed. Is dit eenvoudig te implementeren?

[vso]

Rgerr schreef op woensdag 26 december 2018 @ 15:39:
[...]


Dat laatste, de combinatie, klinkt erg goed. Is dit eenvoudig te implementeren?

https://unix.stackexchang...opies-for-internal-backup

[Blommie01]

Ik weet niet wat je allemaal op je Ubuntu machine hebt draaien, maar wellicht is het handiger om op containers over te stappen.

Installatie script voor je containers maken en al je volumes met Rsync/Tar over SSH backuppen...

Je bent zo veel flexibeler en wanneer je hardware faalt kun je heel snel op elke computer met een docker engine restoren...

[ Voor 7% gewijzigd door Blommie01 op 26-12-2018 16:02 ]

[Rgerr]

vso schreef op woensdag 26 december 2018 @ 15:42:
[...]

https://unix.stackexchang...opies-for-internal-backup

Kun je er een (of meerdere) aanraden?

Blommie01 schreef op woensdag 26 december 2018 @ 15:51:
Ik weet niet wat je allemaal op je Ubuntu machine hebt draaien, maar wellicht is het handiger om op containers over te stappen.

Installatie script voor je containers maken en al je volumes met Rsync/Tar over SSH backuppen...

Je bent zo veel flexibeler en wanneer je hardware faalt kun je heel snel op elke computer met een docker engine restoren...

Heb minder goede verhalen gehoord over Homebridge in Docker, dat schijnt nogal wat issues te hebben. Daar wil ik dus liever niet aan.

[Thralas]

Rgerr schreef op woensdag 26 december 2018 @ 17:16:
Kun je er een (of meerdere) aanraden?

Dat is er niet zo mooi geintegreerd als in Windows. Bovendien leunt het daar op de Volume Shadow Copy service - om iets gelijkwaardigs te krijgen zul je zfs, btrfs of lvm moeten gebruiken onder Linux - en dat levert aardig wat verbouwwerk op.

Voor ZFS: zie sanoid, voor btrfs: Snapper. LVM snapshots zijn zelfstandig niet meer dan een (ietwat achterhaald) bouwblok.

Heb minder goede verhalen gehoord over Homebridge in Docker, dat schijnt nogal wat issues te hebben. Daar wil ik dus liever niet aan.

Dat komt wel erg over als een onderbuikgevoel. Als er één ding handig is aan Docker dan is dat het een ontzettend goed reproduceerbare omgeving oplevert.

En je hebt Docker absoluut niet nodig, maar de charme is wel dat het je enigzins dwingt om alle data in één volume onder te brengen en daarmee compleet gescheiden is van alle zaken die je juist niet wilt backuppen.

Zeker het onderzoeken waard.

Voor wat betreft je originele vraag: ftp is absoluut niet oké op een Linuxmachine - daar gebruik je gewoon scp/sftp (zie @DukeBox) tenzij je hele zwaarwegende redenen hebt om dat niet te doen.

Je manier van backuppen levert daarnaast geen 'iso' op. Een image van een CD heet een ISO, een image van een filesystem is precies dat - een image van een filesystem. En wél een hele beroerde, wat ik neem aan dat je het (draaiende) syteem imaget. Het resultaat daarvan is hartstikke inconsistent, want terwijl je nog aan het imagen bent veranderen er allerlei zaken - absoluut niet zo aanpakken.

(Bovenstaande maakt zfs/btrfs zo ideaal - maar verre van heilig - je kunt in 1x een redelijk consistente snapshot maken)

Ik zou goed uit te zoeken welke zaken je wel/niet wilt backuppen en dan iets als Duplicity of Borg gebruiken om selectief backups op file-niveau te maken en later eens kijken of zfs/btrfs/docker je workflow vergemakkelijkt.

[Blommie01]

Rgerr schreef op woensdag 26 december 2018 @ 17:16:
[...]

Heb minder goede verhalen gehoord over Homebridge in Docker, dat schijnt nogal wat issues te hebben. Daar wil ik dus liever niet aan.

Als ik in de Docker Hub kijk dan is er meer dan voldoende te krijgen voor Homebridge en Domoticz dus die verhalen lijken me nergens op gebaseerd..

https://hub.docker.com/r/oznu/homebridge/

https://hub.docker.com/r/linuxserver/domoticz/

Zou toch eens naar het Docker concept kijken aangaande je wensen... Je maakt het je op deze manier onnodig moeilijk en denkt wat mij betreft de verkeerde kant op. Dit terwijl je behoefte eigenlijk heel erg simpel is..

Blijf vooral weg bij het maken van images van harde schijven. Waarom zou je backups maken van alle bestanden? Dit is ook waarom Docker zo handig is. Je mount een of meerdere mappen in een container zodat je data buiten je containers worden opgeslagen. Backup deze en klaar is...

Voor je database dumps geld hetzelfde. Uit de container halen en backuppen..

Door zo te werken ben je volledig onafhankelijk van een OS. Docker draait namelijk op bijna alle distro’s. Her draait ook op sommige NAS hardware..

Blijf dan ook vooral weg bij het toepassen van virtual machines... Verouderde techniek, zonde van je resourses en verre van flexibel.

Just my 2 cents...

[ Voor 49% gewijzigd door Blommie01 op 26-12-2018 21:31 ]

[vso]

Rgerr schreef op woensdag 26 december 2018 @ 17:16:
[...]


Kun je er een (of meerdere) aanraden?


[...]


Heb minder goede verhalen gehoord over Homebridge in Docker, dat schijnt nogal wat issues te hebben. Daar wil ik dus liever niet aan.

ik ga mee met de rest (docker was ook niet de 1ste gedachte van mij) .. die eerste 1hit op google doorscannen leverde me ook niet 1 van de meest vrolijke oplossingen op, als ik die 2 afweeg --> DOCKER the way to go ..

Terwijl docker inderdaad meer is wat je zoekt .. zet in die "instance" een versioning erbij en je hebt beste van both worlds ofzo .. afhankelijk van het type nas zou je het zelfs daar kunnen draaien.. scheelt je HW

Je backup / recovery testen kan je alleen maar doen als je het doet, en ervaring hebt met het recovery gedeelte ..

[ Voor 5% gewijzigd door vso op 26-12-2018 20:12 ]

[Rgerr]

Na enig zoekwerk ben ik er uit dat het draaien van Docker inderdaad de beste oplossing is. Het jammere is wel dat ik nu alles juist lekker heb draaien, en met Docker wel opnieuw kan beginnen... Maar zal ongetwijfeld de zooi nog eens om zeep helpen, dan is het een mooi moment om met Docker aan de slag te gaan. Of is er een mogelijkheid de huidige setup (alleen Homebridge en Domoticz zijn daarin belangrijk vanwege automation rules binnen iCloud) over te zetten in een Docker?

[JaQ]

Als een eenvoudig bash script niet lukt en je wilt (of kunt) niet bepalen wat relevant is om te backuppen op je server, dan klinkt containerizeren als een bijna onneembare hindernis. Daarvoor heb je immers precies die kennis nodig: meer scripting, inhoudelijke kennis van wat relevant is om te bewaren en als bonus moet je dan ook nog eens docker leren.

Begrijp me goed, containers zijn absoluut de beste route. Echter zeker niet de eenvoudigste oplossing als je basiskennis mist. Je gedachtegang met een iso is dan helemaal niet zo gek, echter wel eerst even alles dat leunt op transacties (lees: databases) stoppen.

Verhalen over documentatie en versiebeheer kloppen ook, maar laat je niet tegenhouden om je eerste paar hobbie-dingetjes voor thuis zonder dat alles te doen. Eerst leren kruipen voordat je gaat rennen.

Simpel en effectief is ook wat waard

[amx]

Rgerr schreef op woensdag 26 december 2018 @ 12:32:
Hallo allemaal,

Ik probeer een bash scriptje te schrijven om mijn Ubuntu server te backuppen naar een .iso bestand en te uploaden via FTP naar mijn NAS op een ander systeem.

Daarvoor moet ik een aantal commando’s uitvoeren, en heb ik hier in een bash script gezet:

code:

#!/bin/bash
ftp 192.168.x.xx
- hier loop ik al vast, ik moet inloggen maar krijg dat niet via script voor elkaar. Ftp user:pass@ip werkt bijvoorbeeld ook niet.
cd /path/naar/backup/locatie/
put "|sudo dd if=/dev/sda" Ubuntu-backup.iso

Tips? Tricks? Tuts? Alle hulp is welkom.

Met een bootable usb kan je, via SSH in plaats van FTP, je oorspronkelijke methode makkelijk uitvoeren:

code:

dd if=/dev/sda | ssh rgerr@192.168.x.x  dd of =/path/naar/backup/locatie/Ubuntu-backup.iso

Bijkomend voordeel van gebruik van bootable usb is dat de bronschijf afgezien van het back-uppen inactief is. Hou er rekening mee dat het traag is (10 MB/s).

[Edit:]
Code verbeterd

[CAPSLOCK2000]

Beetje andere denkrichting maar ik zou geen FTP meer gebruiken. Het is onveilig en onhandig.
SSH / SCP / SFTP is veel handiger.

 cat /dev/sda | ssh <server> "cat > mijnbackup.img"

Let er wel op dat je dit eigenlijk niet mag doen als die schijf in gebruik is, als er naar geschreven wordt terwijl je die backup maakt kan je backup corrupt raken.

[FireDrunk]

@amx volgens mij mist er nog een 'dd' in het tweede gedeelte van het commando

[Rgerr]

amx schreef op donderdag 27 december 2018 @ 09:25:
[...]


Met een bootable usb kan je, via SSH in plaats van FTP, je oorspronkelijke methode makkelijk uitvoeren:

code:

dd if=/dev/sda | ssh rgerr@192.168.x.x  of=/path/naar/backup/locatie/Ubuntu-backup.iso

Bijkomend voordeel van gebruik van bootable usb is dat de bronschijf afgezien van het back-uppen inactief is. Hou er rekening mee dat het traag is (10 MB/s).

En dan zou je het volledige systeem op een usb stick zetten? Of zie ik dat nu verkeerd?

[rjong5]

Iets heel anders, maar waarom niet een programma als veeam agent for linux?

https://helpcenter.veeam....uide/overview.html?ver=20

Je kunt er alles mee wat je wil, backup naar nas, local storage etc. Zelfs encryptie van je backups.

Gebruik het zelf voor windows en linux machines, bare metal restore onder linux nog niet getest maar onder windows werkt dit perfect

[SadisticPanda]

Thralas schreef op woensdag 26 december 2018 @ 18:01:
[...]

Voor wat betreft je originele vraag: ftp is absoluut niet oké op een Linuxmachine - daar gebruik je gewoon scp/sftp (zie @DukeBox) tenzij je hele zwaarwegende redenen hebt om dat niet te doen.

Bler, FTPS doet gaat perfect, en stukken sneller dan sftp/scp (parallellisatie en segmentatie) duwen elke lijn vol.

Thralas schreef op woensdag 26 december 2018 @ 18:01:
[...]

Je manier van backuppen levert daarnaast geen 'iso' op. Een image van een CD heet een ISO, een image van een filesystem is precies dat - een image van een filesystem. En wél een hele beroerde, wat ik neem aan dat je het (draaiende) syteem imaget. Het resultaat daarvan is hartstikke inconsistent, want terwijl je nog aan het imagen bent veranderen er allerlei zaken - absoluut niet zo aanpakken.

Gewoon tar maken van livesysteem met /dev, /proc /tmp, en nog enkele dingen exluded. JA is beetje bruut want logs worden geschreven tijdens tarren, maar maakt weinig uit voor een restore dat enkel log files incompleet zijn.

snapshots zijn idd beter maar in meeste gevallen voldoet een simpele tar ook al op livesyteem. Nog nooit 1 probleem meegehad

[amx]

Rgerr schreef op donderdag 27 december 2018 @ 19:53:
[...]


En dan zou je het volledige systeem op een usb stick zetten? Of zie ik dat nu verkeerd?

Je start op vanaf een live CD/USB omdat er op die manier op /dev/sda geen schrijfbewerkingen worden gedaan.

Je kopieert via dd vervolgens alle sectoren van /dev/sda

Je gebruikt SSH als een doorvoerpijp naar je remote server

Op de remote server worden alle sectoren van /dev/sda als ISO opgeslagen

Met de | tekens in de code wordt een pipe bedoeld