[Raspberry Pi] Automatische backup op NAS

[andregroeneveld]

Hallo allemaal,

Nu ik een stap in de goede richting ben wil toch graag die mount als NFS met mijn NAS maken om daarop de backup image te maken.

1. Als eerste heb ik een map Pi-Hole gemaakt op mijn NAS met lezen en schrijven rechten voor NFS.
2. Daarna de map /mnt/Pi-Hole gemaakt op de RaspberryPi. De juiste rechten gegeven.
3. Deze regel in fstab gezet: 192.168.2.xxx:/c/Pi-Hole /mnt/Pi-Hole nfs comment=systemd.automount.
4. Cronjob gemaakt: 0 18 *** /mnt/Pi-Hole/system_backup.sh het file de juiste rechten gegeven.
5. Het lukt mij nog niet helemaal. Ik heb wel dat de cronjob klopt en er naar het script word gekeken alleen word het niet uitgevoerd omdat ik niet de juiste fstab regel heb.
6. Als proef op de som heb ik in het script gezegd dat hij de backup in de map /mnt/backup moest zetten. Dat lukt wel dus.
7. Dus er word naar het script gekeken maar niet uitgevoerd als ik aangeef waar ik de backup image wil hebben: backup_path=192.168.2.xxx:/c/Pi-Hole.

Kan iemand mij vertellen hoe ik die verbinding met mijn NAS krijg?

[ Voor 5% gewijzigd door andregroeneveld op 12-08-2019 17:22 ]

[ninjazx9r98]

@andregroeneveld
De xxx in het IP adres is zinloos, dit zijn private adressen en alleen intern dus niet op internet te gebruiken.
Wordt er wel een mount gemaakt met NFS? Dit kun je zien met het commando mount.
Als er inderdaad een NFS mount is dan wordt het backup pad /mnt/Pi-Hole en niet wat jij aangegeven hebt.

[L0g0ff]

andregroeneveld schreef op maandag 12 augustus 2019 @ 16:54:
Hallo allemaal,

Nu ik een stap in de goede richting ben wil toch graag die mount als NFS met mijn NAS maken om daarop de backup image te maken.

1. Als eerste heb ik een map Pi-Hole gemaakt op mijn NAS met lezen en schrijven rechten voor NFS.
2. Daarna de map /mnt/Pi-Hole gemaakt op de RaspberryPi. De juiste rechten gegeven.
3. Deze regel in fstab gezet: 192.168.2.xxx:/c/Pi-Hole /mnt/Pi-Hole nfs comment=systemd.automount.
4. Cronjob gemaakt: 0 18 *** /mnt/Pi-Hole/system_backup.sh het file de juiste rechten gegeven.
5. Het lukt mij nog niet helemaal. Ik heb wel dat de cronjob klopt en er naar het script word gekeken alleen word het niet uitgevoerd omdat ik niet de juiste fstab regel heb.
6. Als proef op de som heb ik in het script gezegd dat hij de backup in de map /mnt/backup moest zetten. Dat lukt wel dus.
7. Dus er word naar het script gekeken maar niet uitgevoerd als ik aangeef waar ik de backup image wil hebben: backup_path=192.168.2.xxx:/c/Pi-Hole.

Kan iemand mij vertellen hoe ik die verbinding met mijn NAS krijg?

Ik zou deze stappen eens volgen: https://linuxgain.com/nfs...y-nas-ubuntu-18-04-19-04/

[andregroeneveld]

ninjazx9r98 schreef op maandag 12 augustus 2019 @ 17:54:
@andregroeneveld
De xxx in het IP adres is zinloos, dit zijn private adressen en alleen intern dus niet op internet te gebruiken.
Wordt er wel een mount gemaakt met NFS? Dit kun je zien met het commando mount.
Als er inderdaad een NFS mount is dan wordt het backup pad /mnt/Pi-Hole en niet wat jij aangegeven hebt.

Hi Ninjazx9r98,

Het backup pad moet mijn NAS worden. In /mnt/Pi-Hole staat het script.Ik snap niet precies wat je bedoeld?

[andregroeneveld]

L0g0ff schreef op maandag 12 augustus 2019 @ 19:28:
[...]


Ik zou deze stappen eens volgen: https://linuxgain.com/nfs...y-nas-ubuntu-18-04-19-04/

Ik heb de link opgeslagen. Ik heb geen synolgy NAS maar dat maakt niet uit. Het gaat om het gedeelte om de Pi-Hole goed te krijgen.

[ninjazx9r98]

andregroeneveld schreef op maandag 12 augustus 2019 @ 21:31:
[...]

Hi Ninjazx9r98,

Het backup pad moet mijn NAS worden. In /mnt/Pi-Hole staat het script.Ik snap niet precies wat je bedoeld?

Met de regel in fstab zeg je dat de directory van de nas genaamd Pi-Hole beschikbaar komt onder /mnt/Pi-Hole.
Als je script lokaal staat en niet op de nas dan is deze niet meer beschikbaar na het mounten, daar heb je immers met de fstab regel je nas aan gekoppeld. Aangezien de nas nu beschikbaar is onder /mnt/Pi-Hole moet je in het script ook dat als wegschrijf lokatie aangeven en niet 192.168.enz
Zet het script ergens anders ( bijv /home/pi/scripts , /usr/local/bin ) en ga dan nog eens kijken wat er gebeurt. Denk dat het ook geen kwaad kan om eens te lezen wat je nu precies doet als je iets mount.

Hoe ben je tot de stappen gekomen die je nu uitvoert en wat denk je daarmee te doen (stap voor stap)? Mogelijk maakt dat het eenvoudiger om je in de juiste richting te duwen en aan te geven waar het mis gaat.

[andregroeneveld]

ninjazx9r98 schreef op maandag 12 augustus 2019 @ 23:39:
[...]

Met de regel in fstab zeg je dat de directory van de nas genaamd Pi-Hole beschikbaar komt onder /mnt/Pi-Hole.
Als je script lokaal staat en niet op de nas dan is deze niet meer beschikbaar na het mounten, daar heb je immers met de fstab regel je nas aan gekoppeld. Aangezien de nas nu beschikbaar is onder /mnt/Pi-Hole moet je in het script ook dat als wegschrijf lokatie aangeven en niet 192.168.enz
Zet het script ergens anders ( bijv /home/pi/scripts , /usr/local/bin ) en ga dan nog eens kijken wat er gebeurt. Denk dat het ook geen kwaad kan om eens te lezen wat je nu precies doet als je iets mount.

Hoe ben je tot de stappen gekomen die je nu uitvoert en wat denk je daarmee te doen (stap voor stap)? Mogelijk maakt dat het eenvoudiger om je in de juiste richting te duwen en aan te geven waar het mis gaat.

Sorry, dat ik je niet helemaal snap maar het is voor mij allemaal abrakadabra
Begrijp ik nu dat het script op de NAS of USB moet staan en niet in de map van de RaspberryPi die je linkt aan je NAS of USB? Als dat zo is heb ik het voor mijn USB ook fout.

Ik heb mijn info hiervandaan en dan een beetje veranderd naar mijn situatie.

[waal70]

Wat @ninjazx9r98 zegt...
Ik denk dat je je hele proces even moet opsplitsen:
1) verbinding met je NAS leggen vanaf de PI en dat permanent maken dmv een fstab regel
2) de verbinding gebruiken om je backup naar toe te schrijven

Om bij stap 1 te beginnen:
Je schrijft als entry in fstab:
192.168.2.xxx:/c/Pi-Hole /mnt/Pi-Hole nfs comment=systemd.automount

Dat betekent dat op je pi de map /mnt/Pi-Hole gebruikt gaat worden om te "wijzen" naar de server met ip-adres 192.168.2.xxx, die /c/Pi-Hole als NFS-share heeft. Klopt dat? De "c" in je foldernaam lijkt te wijzen naar een windows-gebaseerde NAS en volgens mij is het gebruikelijker dat die met SMB/CIFS netwerkshares hebben. Ook moeten op je NAS de rechten staan op /c/Pi-Hole zodat je PI daar bestanden mag plaatsen/bewerken.
Niet om overal commentaar op te hebben maar in mijn ogen is het logischer om het mount-point op je PI iets als "NAS" te noemen. Het mount-point wijst immers naar de NAS. Maar goed, dat is geen halszaak.
Anyway, als het allemaal gelukt is, moet je op je PI via /mnt/Pi-Hole dus de bestanden op je NAS kunnen zien (en bewerken)

Dan stap 2: het inplannen van het backup-script.
In theorie is het mogelijk om het script ook op je netwerkshare te zetten. Na succesvolle verbinding plaats je dan het script in /mnt/Pi-Hole. Feitelijk ben je dan via je PI op de NAS aan het werk. Ook hier zou ik zeggen dat je liever het script zelf "lokaal" zou zetten, omdat je dan ook bijvoorbeeld situaties kunt afvangen waarin je netwerk down is, of je NAS down is, en je dan bijvoorbeeld iets alternatiefs kunt doen. Dat betekent dat je een andere map dan /mnt/Pi-Hole moet kiezen voor je script, bijvoorbeeld /home/pi of /usr/local/bin, zoals ook eerder gesuggereerd.
Als je het bestand in /mnt/Pi-Hole plaatst zonder dat de NAS verbonden is, zal het bestand namelijk "verdwijnen" indien de verbinding gelegd wordt. Het verdwijnt niet echt, maar is niet meer te benaderen via /mnt/Pi-Hole (die wijst inmiddels namelijk naar je NAS, niet meer naar het lokale bestandssysteem)

Anyway, in het script gebruik je dan /mnt/Pi-Hole als target voor whatever je wilt backuppen. En als je fstab entry werkt, zal dat je NAS betekenen.

[andregroeneveld]

Hi Waal70, bedankt dat je mij op weg wilt helpen en een twee stappenplan.

Dat betekent dat op je pi de map /mnt/Pi-Hole gebruikt gaat worden om te "wijzen" naar de server met ip-adres 192.168.2.xxx, die /c/Pi-Hole als NFS-share heeft. Klopt dat? Ja, dat klopt!

De "c" in je foldernaam lijkt te wijzen naar een windows-gebaseerde NAS en volgens mij is het gebruikelijker dat die met SMB/CIFS netwerkshares hebben. Ik kan op meerder manier dit doen en heb gekozen voor NFS.
De "c" zag ik elders bij een uitleg staan en dat hielp die gene. Je krijgt ook foutmeldingen zonder die "c" dat de dir niet bestaat.

Ook moeten op je NAS de rechten staan op /c/Pi-Hole zodat je PI daar bestanden mag plaatsen/bewerken.
Dat heb ik gedaan, lezen en schrijven voor de pi en ikzelf uiteraard.

Niet om overal commentaar op te hebben maar in mijn ogen is het logischer om het mount-point op je PI iets als "NAS" te noemen. Het mount-point wijst immers naar de NAS. Maar goed, dat is geen halszaak.
Mee eens.

Anyway, als het allemaal gelukt is, moet je op je PI via /mnt/Pi-Hole dus de bestanden op je NAS kunnen zien (en bewerken). Dit is dus nog niet gelukt. Dus ik ga mij hier op focussen.

[andregroeneveld]

sudo mount /192.168.2.100:/c/Pi-Hole /mnt/Pi-Hole
mount.nfs: Failed to resolve server /192.168.2.100: Name or service not known

sudo mount 192.168.2.100:/c/Pi-Hole /mnt/Pi-Hole
Ik krijg geen foutmelding dus heb ik volgens mij een verbinding, alleen had ik niets in die map staan dus geen controle op een bestand.
Wat er dan is dat ik niet meer iets in map /Pi-Hole kan zetten als ik naar mijn NAS mappen ga met mijn laptop terwijl ik rechten heb. Mogelijk kan er na de mount niet nog iemand anders naar die map. Ga ik dan via WinSCP naar mijn Pi toe naar /mnt/Pi-Hole en zet daar een bestand in dan zie ik het op mijn NAS verschijnen in de map Pi-Hole staan. Dus dan lijkt mij de map gelinkt.

Even gekeken naar mijn USB link. Die is er en ik kan daar ook niet meer iets in veranderen want de eigenaar is van root naar pi gegaan. Alleen vraag ik mij af of dit wel goed is. Ik heb om te testen of ik wel verbinding had met mijn USB het "USB auto mount RaspberryPi3B+.txt" bestand er op gezet en die zie ik nu erbij staan. Allen de rechten zijn naar pi gegaan en ik krijg het niet meer op root???

pi@raspberrypi:~ $ cd /mnt/backup
pi@raspberrypi:/mnt/backup $ ls
system_backup.sh 'USB auto mount RaspberryPi3B+.txt'
'System Volume Information'
pi@raspberrypi:/mnt/backup $

Dus fstab regel blijft volgens mij over, of heb ik iets overgeslagen?

[ Voor 15% gewijzigd door andregroeneveld op 13-08-2019 19:13 ]

[andregroeneveld]

Bedankt Equator voor de aparte post voor automatisch mouten naar de NAS.

Even weer verder hier;
Ik ben er nu achter dat ik geen backup maakte op mijn USB maar gewoon in de map van de pi in de map /mnt/backup.
Als ik het filmpje volg en netjes de stappen doe dan veranderd de map /mnt/backup van eigenaar namelijk van root naar pi na de fstab regel toe te voegen. En alle bestanden die er in staan ook. Ik kan nog wel de rechten veranderen van het script maar niet de eigenaar. Het script wil als root alles uitvoeren en dat klopt ook want als ik de cronjob van tijd verander om te kijken of het werkt dan doet hij niets. Dit heeft met de eigenaar te maken. Ik kan de USB opnieuw formatteren en opnieuw in fstab de uuid opnieuw aanpassen zodat het weer klopt maar nadat ik dit gedaan heb veranderd de eigenaar na een reboot om de USB automatisch te mounten UUID=064A1C614A1C5033 mnt/backup auto nofail,uid=1000,gid=1000,noatime 0 0

Dus ik dacht dat ik het goed had maar eigenlijk niet. Waar ga ik fout?

[MisteRMeesteR]

@andregroeneveld ik heb je laatste post ook weer hiernaartoe verhuisd. Gaarne vanaf nu dit topic gebruiken voor je vragen en opmerkingen rondom het maken van backups, en niet in het algemen Pi-Hole topic s.v.p..

Zie ook deze post van @Equator

Equator in "[Pi-Hole] Ervaringen & discussie"

[andregroeneveld]

Okidokie MisterMeester. Ik heb onderstaande maar weg gehaald bij de andere post omdat ik daar aan het typen was toen jij het veranderde. Daar mag onderstaande dus weggehaald worden.

Ik heb het proces nu diversen malen herhaald maar zodra ik de fstab regel actief zet dan verdwijnt de map /mnt/backup die ik in WinSCP heb gemaakt en krijg ik de nieuw map /mnt/backup maar dan is pi de eigenaar en kan ik niets meer erin zetten. Het lijkt er dus op zodra de mount gemaakt is je er niet meer bij kan en of bestanden die je er al van te voren op gezet hebt om daar eigenaar of rechten van te veranderen. Toch raar dit. Dus nu krijg ik de mount goed maar omdat de eigenaar veranderd kan ik het script er niet in zetten en dus de cronjob kan er ook niets mee. Als ik het cript er van te voren inzet kan ik later nog steeds niet de rechten veranderen van het script of de eigenaar. Ik kom helaas niet verder hiermee.

Dit krijg je dan;
pi@raspberrypi:~ $ sudo mount -a
mount: mnt/backup: mount point does not exist.

[ Voor 103% gewijzigd door andregroeneveld op 13-08-2019 20:52 ]

[The Eagle]

Dat klopt, als jij gaat mounten op een directory dan koppelt ie de bestanden van dat wat op dat mountpoint staat aan die directory. Lokaal spul zie je dan niet meer, hoewel het er fysiek wel staat. Komt doordat er met pointers gewerkt wordt.

Wat je je verder moet bedenken is dat als je dit over en weer wilt kunnen zien, het usernummer en de group van de user die je gebruikt gelijk moeten zijn. Zie je /etc/groups en /etc/passwd van beide machines. Als jij een aparte user aanmaakt op je nas en je pi met zelfde usernummer en group zou het wel goed moeten gaan volgens mij

[andregroeneveld]

The Eagle schreef op dinsdag 13 augustus 2019 @ 20:34:
Dat klopt, als jij gaat mounten op een directory dan koppelt ie de bestanden van dat wat op dat mountpoint staat aan die directory. Lokaal spul zie je dan niet meer, hoewel het er fysiek wel staat. Komt doordat er met pointers gewerkt wordt.

Wat je je verder moet bedenken is dat als je dit over en weer wilt kunnen zien, het usernummer en de group van de user die je gebruikt gelijk moeten zijn. Zie je /etc/groups en /etc/passwd van beide machines. Als jij een aparte user aanmaakt op je nas en je pi met zelfde usernummer en group zou het wel goed moeten gaan volgens mij

Het zegt mij niet zoveel maar ik zie wel die bestandjes staan.
Dubbel staan ze erin: groups en groups- en passwd en passwd-
Wat moet ik dan veranderen?

[ninjazx9r98]

@andregroeneveld
Waarom zou je perse de eigenaar op root willen hebben en niet op pi?
Met de "juiste" rechten voor de User Group of Other maakt het niet uit wie de eigenaar is maar kan iedereen iets Readen, Writen of eXecuten.
Klinkt misschien bot maar domweg video's en handleidingen volgen helpt je wel een eind of volledig op weg maar je hebt mogelijk geen flauw idee wat je gedaan hebt en waarom wat troubleshooten in de toekomst lastig maakt.
Aanpassen van /etc/group ( als het goed is zonder de s ) en /etc/passwd zou ik je absoluut afraden op dit moment bij gebrek aan voldoende kennis.

Dat de user verandert naar pi met de fstab zal kloppen, daar vraag je immers zelf om met de fstab regel.
De user met id 1000 en de group met id 1000 (uid en gid)
Beide kun je terug vinden in /etc/passwd (uid) en /etc/group (gid)
Voor de root user zullen zowel uid als gid 0 moeten zijn wat ook weer terug te vinden is in beide files.

[ Voor 22% gewijzigd door ninjazx9r98 op 13-08-2019 23:04 ]

[andregroeneveld]

Goedemorgen ninjazx9r98,

Aanpassen van /etc/group ( als het goed is zonder de s ) en /etc/passwd zou ik je absoluut afraden op dit moment bij gebrek aan voldoende kennis. Bedankt voor de waarschuwing.

Dat de user verandert naar pi met de fstab zal kloppen, daar vraag je immers zelf om met de fstab regel. Ik volgde simpel weg het filmpje en idd weinig kennis van zaken.

De user met id 1000 en de group met id 1000 (uid en gid). Bedankt voor de uitleg. Weer een stukje duidelijker.

Beide kun je terug vinden in /etc/passwd (uid) en /etc/group (gid). Had ik zien staan.

Voor de root user zullen zowel uid als gid 0 moeten zijn wat ook weer terug te vinden is in beide files.
[/quote]. Ik zal die aanpassen.

Groetjes André,

[andregroeneveld]

De USB opnieuw geformatteerd en van voren af aan gemount. Nu is de mount goed met uid en gid op 0.
Nu is het root en alles wat er in staat. Toch weer wat kennis opgedaan zo.

[SA007]

Move naar NOS, dit is software op een PI, niks met de PI zelf.

[andregroeneveld]

Jawel hoor. Ik probeer een backup van mijn pi SD kaart op een USB en NAS te krijgen. Op de USB heb ik nu eindelijk voor elkaar. De NAS ben ik nog even mee aan het rommelen.Allemaal op de Pi-Hole (software) op de RaspberryPi 3B+

[andregroeneveld]

Jawel hoor. Ik probeer een backup van mijn pi SD kaart op een USB en NAS te krijgen. Op de USB heb ik nu eindelijk voor elkaar. Dacht ik maar nog steeds niet

De NAS ben ik nog even mee aan het rommelen.Allemaal op de Pi-Hole (software) op de RaspberryPi 3B+ (hardware).

[ Voor 9% gewijzigd door andregroeneveld op 15-08-2019 18:03 ]

[FightingAce]

Wat je wilt doen is niet bepaald uniek voor PiHole. Het mounten van een NAS is uiteindelijk een algemene Linux vraag.

[andregroeneveld]

Weet je, een moderator heeft mij hier neergezet. Dus wie ben ik om daar tegen in te gaan.

[andregroeneveld]

Helaas nog steeds niet een backup van mijn pi-hole kunnen maken op de USB. Ik dacht dat ik het goed had maar toch niet.
Als ik van te voren het backup script op de USB zet kan ik zodra deze gemount is niet meer de rechten veranderen. De rechten van de map /mnt/backup die veranderd ook van 0775 terug naar 700 na een reboot.
De file system_backup.sh krijgt 0600 waar het sript in staat word dus niet uitgevoerd.
Het script later er naar toe kopieren lukt niet want dan krijg ik de melding dat ik de rechten niet heb. Dus links om of rechts om ik krijg niet voor elkaar dat ik in de map wat mag uitvoeren dus ook niet een backup image neerzetten.
Hoe krijgt men het voor elkaar wanneer de USB gemount is dat daar het script in staat met de juiste rechten?

[ninjazx9r98]

@andregroeneveld
Wat voor type filesystem heeft de usb? Als dat ntfs, fat32 oid is dan kun je sowieso geen linux rechten gebruiken. Snap overigens nog steeds niet waarom je het script perse op de usb wil hebben. Zet het lekker lokaal op de pi, dan kun je het gebruiken voor ieder usb device dat gemount is.
Om meer rechten te hebben na het mounten zul je dat moeten toevoegen aan je fstab regel, bijv rw en exec.
Uitvoeren en neerzetten oftewel Write en eXecute is niet hetzelfde in linux.
Kun je concreter worden wat je precies wil bereiken, welke user je gebruikt en wanneer je die 775 rechten ziet/zet?
Je springt een beetje van de hak op de tak

Ps
Een script hoeft geen execute rechten te hebben om het te kunnen uitvoeren.
"sh system_backup.sh" werkt ook, moet je wel nog even de juiste paden naar beide ervoor zetten.

[ Voor 12% gewijzigd door ninjazx9r98 op 15-08-2019 19:42 ]

[Hero of Time]

Hoe krijgt men het voor elkaar wanneer de USB gemount is dat daar het script in staat met de juiste rechten?

Dat leer je door je in te lezen in het mount systeem van Linux, de verschillende file systems die het ondersteund, de opties die hier mogelijk zijn en welke van die opties je moet gebruiken.

Standaard heeft een USB stick geen zogenoemd POSIX file system. Dat wil zeggen dat het geen 'native' Linux file system is dat het uitgebreide rechtensysteem ondersteund. Een veel gebruikt file system voor USB storage is FAT32. Dat kent helemaal geen rechten structuur. Het wordt daarom in Linux tijdens het mounten bepaald wie er mag schrijven door het UID en GID van de betreffende gebruiker en groep op te geven. Doe je dat niet, dan wordt de eigenaar gezet op de gebruiker die het mount commando uitvoert en standaard mag alleen root schijven koppelen.

Het hele probleem waar je in dit topic tegenaan loopt is je gebrek aan kennis van zowel Linux als het mounten van schijven, zowel lokale, verwisselbare als netwerkschijven. Al die kennis is te veel om in een topic uitgebreid te gaan uitleggen. Dat kan je veel beter online opzoeken, want het is al uitvoerig omschreven op talloze sites.

[andregroeneveld]

ninjazx9r98 schreef op donderdag 15 augustus 2019 @ 19:34:
@andregroeneveld
Wat voor type filesystem heeft de usb? Als dat ntfs, fat32 oid is dan kun je sowieso geen linux rechten gebruiken. Snap overigens nog steeds niet waarom je het script perse op de usb wil hebben. Zet het lekker lokaal op de pi, dan kun je het gebruiken voor ieder usb device dat gemount is.
Om meer rechten te hebben na het mounten zul je dat moeten toevoegen aan je fstab regel, bijv rw en exec.
Uitvoeren en neerzetten oftewel Write en eXecute is niet hetzelfde in linux.
Kun je concreter worden wat je precies wil bereiken, welke user je gebruikt en wanneer je die 775 rechten ziet/zet?
Je springt een beetje van de hak op de tak

Ps
Een script hoeft geen execute rechten te hebben om het te kunnen uitvoeren.
"sh system_backup.sh" werkt ook, moet je wel nog even de juiste paden naar beide ervoor zetten.

Hi ninjazx9r98,

Wat ik bereiken wil is een backup vab mijn Pi-Hole image maken met een cronjob. Ik wil dit eerst op de USB zetten die NTFS is. Daarna op mijn Netgear NAS. Maar eerst wil ik het op de USB voor elkaar krijgen. Ook om te leren van het proces. Dus focus ik mij eerst op die USB. Het mounten lukt mij nu en ben er ook achter dat ik uid en gid op 0 moet zetten voor root.
Ik heb begrepen van het forum dat system_backup.sh in de map moet staan waar je je backup in schrijft en die is dan gemount aan je USB dus komt hij op je USB.
Ik begrijp nu van jou dat het niet uitmaakt waar je dat script hebt staan want als er maar in het script staat waar hij het schrijven moet. Al dat zo is ga ik dat eerst eens proberen.

[ninjazx9r98]

@andregroeneveld
Zo is het een stuk duidelijker en inderdaad, het script hoeft niet op dezelfde locatie te staan als de locatie waar de backup geschreven wordt.

[Hero of Time]

@andregroeneveld, heb je mijn post ook goed gelezen? Als je iets hebt gemount, mag root er in principe altijd in schrijven, tenzij je 'm als alleen-lezen mount. Het maakt daarom niet uit of je stick nou NTFS of FAT32 is, of je het uid 0 geeft of 1000, root mag er altijd in schrijven.

Alleen NFS heeft een uitzondering voor root als root_squash_fs optie aan staat op de server.

Je doet er goed aan om je meer te verdiepen in de verschillende zaken omgaande Linux zoals dus het mounten van file systems.

[Freee!!]

ninjazx9r98 schreef op donderdag 15 augustus 2019 @ 21:26:
[...]
het script hoeft niet op dezelfde locatie te staan als de locatie waar de backup geschreven wordt.

Er is één (klein) voordeel aan het delen van de locatie van scrip en backup: Als het script gestart wordt (kan worden), weet je dat de doellocatie bereikbaar is.

[andregroeneveld]

Okay, ik heb het script in /mnt gezet. In het script zeg ik dat er naar /mnt/usb geschreven moet worden die gemount is aan mijn USB. Maar hij doet het niet.
Als ik mijn usb un mount en het script in de map /mnt/backup zet dan maakt hij daar de backup image in. Dus ik krijg wel voor elkaar om in zich zelf te schrijven maar zodra hij gemount is doet hij het niet.
(Sterker nog ik heb het ook voor elkaar dat ik de map/mnt/Pi-Hole gemount heb op mijn NAS naar de map Pi-Hole en daar staat het script in en die doet het wel. Alleen mijn NAS gaat aan en uit op een tijdklok en daar heeft de Pi-Hole op een of andere manier last van dat de verbinding ineens weg valt.) Maar weer terug naar de USB. Hoe kan dat toch dat hij niet naar de USB schrijft?
cronjob is bijvoorbeeld: 32 21 * * * /mnt/system_backup.sh
USB is gemount aan /mnt/usb
script staat in /mnt

[andregroeneveld]

Hero of Time schreef op donderdag 15 augustus 2019 @ 21:40:
@andregroeneveld, heb je mijn post ook goed gelezen? Als je iets hebt gemount, mag root er in principe altijd in schrijven, tenzij je 'm als alleen-lezen mount. Het maakt daarom niet uit of je stick nou NTFS of FAT32 is, of je het uid 0 geeft of 1000, root mag er altijd in schrijven.

Alleen NFS heeft een uitzondering voor root als root_squash_fs optie aan staat op de server.

Je doet er goed aan om je meer te verdiepen in de verschillende zaken omgaande Linux zoals dus het mounten van file systems.

Ik krijg de USB gemount als root maar het lukt niet dat hij een backup image maakt van de pi.

[ninjazx9r98]

@andregroeneveld
Denk dat niemand hier een kristallen bol heeft dus "doet het niet" zegt niet zo veel. Wat gebeurt er precies, krijg je foutmeldingen en wat staat er eigenlijk in het script?

[andregroeneveld]

Hij doet het ineens????????????????
Ik doe het zelfde wat ik al de hele avond aan het doen ben. Ondertussen is vrouwlief boos naar boven toe
cronjob is bijvoorbeeld: 43 21 * * * /mnt/system_backup.sh
USB is gemount aan /mnt/usb
script staat in /mnt

Alleen heb ik nu een sudo reboot gegeven na de cronjob.

Script heb ik van Freee!!

Bash:

#!/bin/bash
#
# Automate Raspberry Pi Backups
#
# Usage: system_backup.sh {path} {days of retention}
#
# Below you can set the default values if no command line args are sent.
# The script will name the backup files {$HOSTNAME}.{YYYYmmdd}.img
# When the script deletes backups older then the specified retention
# it will only delete files with it's own $HOSTNAME.
#

# Declare vars and set standard values
backup_path=/mnt/usb
retention_days=3
block_size=4M
ImageName=$HOSTNAME.$(date +%Y%m%d_%H).img

# Check that we are root!
if [[ ! $(whoami) =~ "root" ]]; then
echo ""
echo "**********************************"
echo "*** This needs to run as root! ***"
echo "**********************************"
echo ""
exit
fi

# Check to see if we got command line args
if [ ! -z $1 ]; then
   backup_path=$1
fi

if [ ! -z $2 ]; then
   retention_days=$2
fi

# Create trigger to force file system consistency check if image is restored
touch /boot/forcefsck

# Perform backup
# dd if=/dev/mmcblk0 of=$backup_path/$HOSTNAME.$(date +%Y%m%d).img bs=4M
dd if=/dev/mmcblk0 bs=$block_size | gzip > $backup_path/$HOSTNAME.$(date +%Y%m%d_%H).img.zip
# dd if=/dev/mmcblk0 of=$backup_path/$ImageName bs=$block_size
# gzip -c $backup_path/$ImageName > $backup_path/$ImageName.zip
# rm $backup_path/$ImageName

# Remove fsck trigger
rm /boot/forcefsck

# Delete old backups
find $backup_path/$HOSTNAME.*.img.zip -mtime +$retention_days -type f -delete

[ Voor 71% gewijzigd door Hero of Time op 15-08-2019 21:56 . Reden: reactie samengevoegd en code blocks in quote ivm lengte ]

[andregroeneveld]

Edit je berichten ipv een nieuwe te posten kort na je vorige. Zie ook het algemeen beleid hierover. Ik heb je reacties nu handmatig samengevoegd.

[ Voor 96% gewijzigd door Hero of Time op 15-08-2019 21:55 ]

[ninjazx9r98]

@andregroeneveld
Waarom die reboot, het is geen Windows

@Freee!!
Is wel een heel lelijke methode om dat te testen en ik zou dat liever testen in het script zelf met een nette melding als het niet zo is maar het klopt inderdaad wel.

[Hero of Time]

andregroeneveld schreef op donderdag 15 augustus 2019 @ 21:42:
Alleen mijn NAS gaat aan en uit op een tijdklok en daar heeft de Pi-Hole op een of andere manier last van dat de verbinding ineens weg valt.

Dat is een slecht idee. Je NAS zomaar uitschakelen via een tijdschakelaar is hetzelfde als je PC telkens uitzetten door de stekker eruit te trekken. Je gaat hier na verloop van tijd gezeik mee krijgen. Is het niet corrupte data, dan is het wel defecte schrijven of andere hardware mankementen. Een NAS is gemaakt om 24/7 aan te staan.

andregroeneveld schreef op donderdag 15 augustus 2019 @ 21:43:
[...]

Ik krijg de USB gemount als root maar het lukt niet dat hij een backup image maakt van de pi.

Je moet dan wel mounten met de rw optie. Ik bedenk mij ook net dat er twee NTFS oplossingen zijn voor Linux. Eentje is ondersteund in de kernel via 'mount -t ntfs', de ander is via fuse in userspace wat veel beter werkt en in het package ntfs-3g te vinden is. Je mount dan met 'mount -t ntfs-3g'.

Is er ook een reden waarom je de stick NTFS hebt gemaakt?

[Freee!!]

ninjazx9r98 schreef op donderdag 15 augustus 2019 @ 21:51:
[...]
@Freee!!
Is wel een heel lelijke methode om dat te testen en ik zou dat liever testen in het script zelf met een nette melding als het niet zo is maar het klopt inderdaad wel.

Direct toegegeven, maar ik heb het script ook maar overgenomen en een beetje naar mijn smaak aangepast, ik ben niet zo goed, dat ik die test kan coderen.

[andregroeneveld]

Freee!! schreef op donderdag 15 augustus 2019 @ 21:41:
[...]

Er is één (klein) voordeel aan het delen van de locatie van scrip en backup: Als het script gestart wordt (kan worden), weet je dat de doellocatie bereikbaar is.

Maar dat is mij helaas niet gelukt.

Hero of Time schreef op donderdag 15 augustus 2019 @ 21:54:
[...]

Dat is een slecht idee. Je NAS zomaar uitschakelen via een tijdschakelaar is hetzelfde als je PC telkens uitzetten door de stekker eruit te trekken. Je gaat hier na verloop van tijd gezeik mee krijgen. Is het niet corrupte data, dan is het wel defecte schrijven of andere hardware mankementen. Een NAS is gemaakt om 24/7 aan te staan.
Dat gaat netjes via de tijdschakelaar in de NAS zelf. Niet zo klok er tussen

[...]

Je moet dan wel mounten met de rw optie. Ik bedenk mij ook net dat er twee NTFS oplossingen zijn voor Linux. Eentje is ondersteund in de kernel via 'mount -t ntfs', de ander is via fuse in userspace wat veel beter werkt en in het package ntfs-3g te vinden is. Je mount dan met 'mount -t ntfs-3g'.

Is er ook een reden waarom je de stick NTFS hebt gemaakt? Omdat ik dat via het youtube filmpje ook zag. Die heb ik nu weer FAT 32 gemaakt. Misschien is dat wel de reden dat het nu lukt.

Zie vetgedrukt.

[ Voor 62% gewijzigd door Hero of Time op 15-08-2019 22:05 ]

[andregroeneveld]

Modbreak:

Je hebt nu ook een ontevreden moderator op je dak. Ik wil je echt met klem benadrukken dat het plaatsen van meerdere reacties direct na elkaar zeer ongewenst is. Zie Het algemeen beleid #verbodenanders:

Je probleem binnen 24 uur met een 'schopreactie' onder de aandacht brengen. Als je iets nieuws toe te voegen hebt aan je topic binnen die 24 uur en je bent zelf de laatste poster, dan kun je je post bewerken.

Blijf je dubbelposten, dan ben ik genoodzaakt verdere maatregelen te nemen.

[ Voor 88% gewijzigd door Hero of Time op 15-08-2019 22:04 ]

[andregroeneveld]

Helaas is zaterdagochtend de sd kaart overleden. Een sd uit een 2e telefoon gehaald om de Image terug te zetten maar dat lukte niet omdat ik niet het juiste programma had gebruikt. Daarom heb ik opnieuw de installatie gedaan. Toen kwam het moment om de usb te mounten en het script voor de back-up uit te laten voeren. Ondanks dat ik alles netjes in een documentje had staan stap voor stap lukte het mounten probleemloos maar de cronjob uit te laten voeren niet. Ik ben dus een stapje terug gegaan door het script uit te laten voeren in /mnt/usb en naar het script kijken in /mnt/usb en ook geprobeerd kijken in /mnt.
Wat mij opviel is dat ik de cronjob op 3 manieren kon laten uitvoeren en ook op 3 verschillende plaatsen terechtkomt namelijk met commando sudo crontab -e, crontab -e en sudo nano crontab -e. Ik heb alle 3 bekeken en in alle 3 een regel ingevoerd (niet gelijktijdig) maar het script word niet gestart.
Ik heb het script opnieuw gekopieerd van het forum (en aangepast aan mijn back-up map) en opnieuw opgeslagen. Ook hier geen succes mee.
Door dit te doen kan ik wel het script laten uitvoeren:
cd /mnt/usb
sudo ./system_backup.sh
Alleen krijg ik een backup van ruim 60GB terwijl dat eerder rond de 2GB was. Lijkt wel of er een backup van de hele sd kaart gemaakt word. Moet ik dan het script ergens aanpassen?

Heeft iemand een idee waarom het via een cronjob niet lukt? Moet ik nog iets installeren?

[ Voor 6% gewijzigd door andregroeneveld op 18-08-2019 12:46 ]

[Freee!!]

Het script maakt inderdaad een backup van de hele SD kaart, daarom ook dat ik de gzip erbij heb gefrot.

[ninjazx9r98]

@andregroeneveld
Hij doet het niet zonder verdere informatie gaat zo goed als zeker geen zinnige hulp opleveren. Wat staat er in de logfiles als cron niet werkt? Kijk onder andere in syslog, daemon.log, auth.log in /var/log of doe vrij grof een "grep cron *" in /var/log en kijk wat er voorbij komt.
Over het algemeen bevatten logfiles van een Linux installatie goed leesbare zinnige informatie.

[andregroeneveld]

In var/auth.log staan veel regels met cron erin. Zoals deze en soms gaan ze eindeloos door.
Aug 18 09:25:05 raspberrypi CRON[430]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 18 09:25:05 raspberrypi CRON[431]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 18 09:25:05 raspberrypi CRON[431]: pam_unix(cron:session): session closed for user root

Maar om het allemaal nog vreemder te maken.Ik kreeg geen cronjob voor elkaar om een back-up te maken in /mnt/usb dus deed ik die handmatig met als gevolg een back-up image van +/- 5.5 GB wat afwijkend is van voor zaterdagochtend, want die waren allemaal rond de 2GB.
Als proef op de som had een cronjob voor in de map /mnt/nas gemaakt en die is gewoon uitgevoerd alleen is die +/- 59 GB groot. Daar is weinig aan gezipt lijkt mij. Dus de cronjob word wel uitgevoerd voor naar mijn /mnt/nas en is belachelijk groot maar niet voor naar /mnt/usb terwijl alle mappen chmod 775 zijn.

[ Voor 42% gewijzigd door andregroeneveld op 18-08-2019 17:22 ]

[Hero of Time]

Kijk eens in je script en probeer te begrijpen wat er gebeurt. Grote kans dat er in het script dat je gebruikt voor naar je NAS geen gzip wordt uitgoerd tijdens het maken van de backup en naar /mnt/usb wel.

[andregroeneveld]

Dat zou je denken Hero maar ze zijn exact hetzelfde op deze regel backup_path=/mnt/usb na want die wordt simpel backup_path=/mnt/nas.

[ninjazx9r98]

Je hebt sowieso iets vreemds in je script. Je gebruikt dd met if (input file) maar hebt vervolgens geen of (output file). Werkt kennelijk wel hoe je het nu oplost maar netjes is het niet.
Pas je cron entry eens aan naar 1 van de volgende en kijk dan eens in de file die gemaakt wordt.

code:

1 2 * * * /path/to/your/command &>/tmp/mycommand.log
1 2 * * * /path/to/your/command >/tmp/mycommand.log 2>&1

[Hero of Time]

ninjazx9r98 schreef op zondag 18 augustus 2019 @ 19:55:
Je hebt sowieso iets vreemds in je script. Je gebruikt dd met if (input file) maar hebt vervolgens geen of (output file). Werkt kennelijk wel hoe je het nu oplost maar netjes is het niet.

Waarom is het niet netjes? Als je geen output file opgeeft bij dd, wordt het standaard naar stdout gestuurd. Ideaal als je het dan piped naar bijvoorbeeld gzip, wat in z'n script dus ook wordt gedaan. Zo heb je niet de ruimte van meer dan een hele schijf nodig om een backup te maken.

Je kan het principe bij meerdere programma's toepassen, zoals mysqldump en pgdump om je database backup direct in te pakken.

[ninjazx9r98]

@Hero of Time
Had in m'n hoofd zitten dat "of" altijd gebruikt dient te worden, doe dat zelf ook altijd en even compleet vergeten dat het normaal naar stdout gaat.

[andregroeneveld]

Het script is van Freee (in post 9 van deze pagina) en werkt bij iedereen goed. Dat deed het bij mij ook totdat mijn sd kaart stuk ging.Vanochtend stond er een backup image van 45 GB in de map /mnt/usb. Dus die cronjob is uitgevoerd om 0 3 * * * /mnt/usb/system_backup.sh
Er zijn dus voor mij 2 vreemde dingen namelijk dat de backup image belachelijk groot is en enorm varieert in grootte. Het lijkt we de hele sd kaart met ook de delen wat niet gebruikt word.
Als ik er een cronjob inzet die even 10 minuten verder is na nu en daarop wacht gebeurd er niets of het lijkt zo omdat +/- 60 GB backup maken gaat heel traag. Maar met commando ps faux zie alle processen en geen cronjob oid staan.
Ik heb deze installatie Webmin niet geïnstalleerd maar dat was eigenlijk wel handig want je zag dat de processor arbeid in % toenemen en dat er gebruik gemaakt werd van het swap geheugen.
Wat mij vanochtend ook opvalt is dat de processor temperatuur net iets boven de 60 graden is terwijl die normaal 47 graden is. Waarschijnlijk omdat het hele sd kaartje vol staat door die grote backup file.
Ik heb met WinSCP dat grote file weg gehaald maar moet dan even sudo reboot doen voordat de temperatuur weer gaat zakken.een hoop onzekerheden nog.
De 1e vraag is dan ook, hoort de back-up zo te gaan een hele sd van 64 GB incl. ongebruikte ruimte en ging het back-uppen voorheen niet goed?

[ Voor 13% gewijzigd door andregroeneveld op 19-08-2019 11:45 ]

[Freee!!]

andregroeneveld schreef op maandag 19 augustus 2019 @ 07:53:
Het script is van Freee (in post 9 van deze pagina)

Niet van mij, ik heb het ook maar ergens van het internet opgeduikeld en er nog een beetje aan gefröbeld tot het naar mijn smaak was.

en werkt bij iedereen goed. Dat deed het bij mij ook totdat mijn sd kaart stuk ging.Vanochtend stond er een backup image van 45 GB in de map /mnt/usb. Dus die cronjob is uitgevoerd om 0 3 * * * /mnt/usb/system_backup.sh
Er zijn dus voor mij 2 vreemde dingen namelijk dat de backup image belachelijk groot is en enorm varieert in grootte. Het lijkt we de hele sd kaart met ook de delen wat niet gebruikt word.

Dat klopt, DD pakt gewoon de hele SD-kaart, heb ik al eerder verteld.

Als ik er een cronjob inzet die even 10 minuten verder is na nu en daarop wacht gebeurd er niets of het lijkt zo omdat +/- 60 GB backup maken gaat heel traag. Maar met commando ps faux zie alle processen en geen cronjob oid staan.
Ik heb deze installatie Webmin niet geïnstalleerd maar dat was eigenlijk wel handig want je zag dat de processor arbeid in % toenemen en dat er gebruik gemaakt werd van het swap geheugen.
Wat mij vanochtend ook opvalt is dat de processor temperatuur net iets boven de 60 graden is terwijl die normaal 47 graden is. Waarschijnlijk omdat het hele sd kaartje vol staat door die grote backup file.
Ik heb met WinSCP dat grote file weg gehaald maar moet dan even sudo reboot doen voordat de temperatuur weer gaat zakken.een hoop onzekerheden nog.
De 1e vraag is dan ook, hoort de back-up zo te gaan een hele sd van 64 GB incl. ongebruikte ruimte en ging het back-uppen voorheen niet goed?

Ja, die backup hoort zo te gaan en om de omvang een beetje binnen de perken te houden, heb ik die gzip toegevoegd. Die hoge temperatuur komt niet door het volle kaartje, maar doordat de processor vrij hard moet werken voor dd en gzip.

[andregroeneveld]

Hi Freee!!, bedankt voor je antwoorden.
Dus als ik het goed begrijp waren de vorige gezipte back-ups van +/- 2 GB en uitgepakt +/- 4,5 GB eigenlijk niet goed?
Zo`n image terugzetten gaat dan ook nooit werken want die is mogelijk alleen van de boot sector want de rest is te groot geweest?
Ik heb er een 8 GB USB stick inzitten, gaat dus nooit goed werken?
Het is dus niet gunstig om er een 64 GB sd kaart in te hebben want dan krijg je grote back-ups?
Ik kan dus beter energie stoppen in het voor elkaar krijgen een back-up op de NAS te zetten die is toch groot genoeg?

[Freee!!]

andregroeneveld schreef op maandag 19 augustus 2019 @ 12:05:
Hi Freee!!, bedankt voor je antwoorden.
Dus als ik het goed begrijp waren de vorige gezipte back-ups van +/- 2 GB en uitgepakt +/- 4,5 GB eigenlijk niet goed?

Die kunnen best goed geweest zijn, afhankelijk van de inhoud van de kaart (allemaal null-waardes comprimeert heel lekker).

Zo`n image terugzetten gaat dan ook nooit werken want die is mogelijk alleen van de boot sector want de rest is te groot geweest?

De bootsector op een SD-kaartje voor een Pi is normaal zo'n 64 MB groot (heb ik opgerekt naar 256 MB voor updates), de rest past gemakkelijk in 8 GB.

Ik heb er een 8 GB USB stick inzitten, gaat dus nooit goed werken?

Waarschijnlijk niet als backup.

Het is dus niet gunstig om er een 64 GB sd kaart in te hebben want dan krijg je grote back-ups?

Dat heeft voor en nadelen, ik heb er een 32 GB SD-kaartje in zitten.

Ik kan dus beter energie stoppen in het voor elkaar krijgen een back-up op de NAS te zetten die is toch groot genoeg?

Ook die USB-stick is een deel van je NAS, net als de USB-HDD. NAS is gewoon Network Attached Storage. Het maakt technisch totaal geen verschil of je een USB-stick of een USB-HDD gebruikt. Maar zorg ervoor, dat je een bruikbaar file system gebruikt en laat dat ding aan je Pi zitten, niet elke keer eraf halen en aan je Windowsbak hangen.

[andregroeneveld]

Freee!!@
Die kunnen best goed geweest zijn, afhankelijk van de inhoud van de kaart (allemaal null-waardes comprimeert heel lekker).
Waarom nu dan van die grote back-ups?

De bootsector op een SD-kaartje voor een Pi is normaal zo'n 64 MB groot (heb ik opgerekt naar 256 MB voor updates), de rest past gemakkelijk in 8 GB.
Was ook maar gissen vanwege de grootte van de vorige back-ups.

Waarschijnlijk niet als backup.
Duidelijk dan gaat hij eruit.

Dat heeft voor en nadelen, ik heb er een 32 GB SD-kaartje in zitten.
Ik laat hem toch zitten want ik heb niet kleiner

Ook die USB-stick is een deel van je NAS, net als de USB-HDD. NAS is gewoon Network Attached Storage. Het maakt technisch totaal geen verschil of je een USB-stick of een USB-HDD gebruikt. Maar zorg ervoor, dat je een bruikbaar file system gebruikt en laat dat ding aan je Pi zitten, niet elke keer eraf halen en aan je Windowsbak hangen.
Dat snap ik maar mijn NAS gaat door de weeks in de avond om 23:00 uur uit en dat vind die pi-hole niet fijn heb ik gemerkt.

Ik heb een script van een iemand gekregen om zijn domotica die draait op een pi te back-uppen naar zijn NAS als cifs. Ik heb het vergeleken met het script dat ik al heb maar weet niet hoe ik dit kan ombouwen.
Ik krijg alleen die tekst niet zoals jullie dat doen met code erboven.

code:

[b]#!/bin/bash

### This will backup your database, scripts and LUA to your NAS drive
### USER CONFIGURABLE PARAMETERS

DESTDIR="/home/pi/backup2Nas"   # used for: NAS
MOUNTPATH="//192.168.2.100/pihole/system_backup.sh"
USERNAME="XXXXX"
PASSWORD="@XXXXX"

### END OF USER CONFIGURABLE PARAMETERS
TIMESTAMP=`/bin/date +%d%m%Y%H%M%S`
BACKUPFILE="domoticz_$TIMESTAMP.db"
BACKUPFILEGZ="$BACKUPFILE".gz
MOUNTCOMMAND="sudo mount -t cifs -o username=$USERNAME,password=$PASSWORD $MOUNTPATH $DESTDIR"

### check of mountpath bestaat en anders aanmaken
if [ -d "$DESTDIR" ]
then
   echo "$DESTDIR directory  exists!"
else
   echo "$DESTDIR directory not found!"
   mkdir $DESTDIR
fi

### mount
$MOUNTCOMMAND

/usr/bin/curl -s http://192.168.178.39:8080/backupdatabase.php > /tmp/$BACKUPFILE
echo zip up local database
gzip -9 /tmp/$BACKUPFILE

cd /tmp
mkdir /tmp/backup
cp -r /home/pi/domoticz/scripts/* /tmp/backup
echo tar scripts and LUA files
tar -zcvf scripts_$TIMESTAMP.tar.gz /tmp/backup/*

echo transferring backups to NAS drive
cp /tmp/$BACKUPFILEGZ $DESTDIR
cp /tmp/scripts_$TIMESTAMP.tar.gz $DESTDIR
echo "A copy of database, scripts and LUA are now on your NAS"
 
echo deleting old files used in making backups
/bin/rm /tmp/$BACKUPFILEGZ
/bin/rm /tmp/scripts_$TIMESTAMP.tar.gz
/bin/rm -rf /tmp/backup

echo checking for and deleting old backups from NAS
# Delete domoticz backup and scripts files older than 5 days from NAS
sudo find /$DESTDIR/domoticz_* -type f -mtime +5 -delete
sudo find /$DESTDIR/scripts_* -type f -mtime +5 -delete

### unmount
sudo umount $DESTDIR[/b]

[ Voor 68% gewijzigd door andregroeneveld op 19-08-2019 18:20 ]

[ninjazx9r98]

@andregroeneveld
Die code krijg je door gebruik te maken van de juiste codes

code:

[code]Het stuk script dat je wil laten zien[/code]

Datzelfde wordt normaal gesproken ook gedaan met zogenaamde quotes. net even anders dan jouw manier om met vetgedrukte tekst te werken. In plaats van code tussen de blokhaken gebruik je dan quote en /quote.

Voor wat betreft het script dat je geplaatst hebt, dat is puur om een back-up te maken van Domoticz en niet van de volledige Pi. Het maakt een database back-up en kopieert de script files die bij Domoticz horen en daar houdt het mee op.

En de vraag waarom de back-ups nu zo groot zijn kun alleen jij beantwoorden, niemand hier weet hoeveel ruimte je in gebruik hebt en of je niet per ongeluk back-ups ergens hebt staan op een plek waar je het niet verwacht maar die wel ruimte vreten. Je hebt immers meerdere keren aangegeven dat de back-up niet werkte maar wat nu als dat wel het geval was maar het alleen ergens anders terecht gekomen is dan je dacht?
Kijk eens met "df -h" wat de vulling is van je SD.

[andregroeneveld]

code:

pi@raspberrypi:~ $ df -h
Filesystem              Size    Used    Avail   Use% Mounted on
/dev/root                 59G     1.8G   55G      4% /
devtmpfs                459M    0        459M    0% /dev
tmpfs                     464M     668K  463M   1% /dev/shm
tmpfs                     464M     6.2M  457M   2% /run
tmpfs                     5.0M     4.0K   5.0M     1% /run/lock
tmpfs                     464M    0        464M    0% /sys/fs/cgroup
/dev/mmcblk0p1   253M    40M   214M    16% /boot
tmpfs                     93M     0         93M      0% /run/user/999
tmpfs                     93M     0         93M      0% /run/user/1000
pi@raspberrypi:~ $

[ Voor 12% gewijzigd door andregroeneveld op 19-08-2019 18:33 ]

[ninjazx9r98]

@andregroeneveld
Heb je niet voor niets uitgelegd hoe je die code tags kunt gebruiken
Weet je zeker dat je back-up file gezipt is /wordt?
Met het commando "file <backupfile>" moet je dat kunnen zien. Doe ik dat bij op een gezipte logfile dan zie je dit:

code:

pi@pihole:~ $ file /var/log/syslog.2.gz
/var/log/syslog.2.gz: gzip compressed data, last modified: Sat Aug 17 22:00:01 2019, from Unix, original size 76941

PS
Ik zag je ook schrijven dat je met het ps commando zocht naar cron, denk dat je beter kunt zoeken naar dd of gzip aangezien dat de processen zijn waar je echt naar op zoek bent. Denk ook dat je niet voldoende geduld hebt om af te wachten of de back-up nog loopt en dat zou ook meteen verklaren waarom de temperatuur hoog blijft. De temperatuur blijft hoog omdat de back-up nog loopt maar jij breekt deze af met een reboot en ziet deze vervolgens een stuk lager na het opnieuw booten wat niet zo vreemd is aangezien het proces dat de temperatuur laat oplopen net daarvoor de nek is omgedraaid

[ Voor 40% gewijzigd door ninjazx9r98 op 19-08-2019 18:42 ]

[Hero of Time]

Om antwoord te geven op de vraag waarom je backup nu zo groot is, kan je vertellen hoe vol de SD kaart was:

Een sd uit een 2e telefoon gehaald

Als die vol met foto's stond en andere zooi, dan blijft dat er staan. Met dd wordt er een ruwe dump gemaakt. Als je bestanden verwijdert, wordt de verwijzing naar het bestand weggehaald, maar fysiek op de schijf, maar ook dus geheugenkaartjes, staat het er nog. Dat is hoe je met data herstel software je per ongeluk verwijderde document of foto's terug kan halen. Omdat het bestand zelf nog niet weg is of overschreven door andere data.

Dus, als die kaart voor zo'n 50 GB vol heeft gestaan, zal gzip weinig kunnen om het kleiner te maken omdat er eigenlijk gewoon data staat.

Wil je deze ruimte, wat je denkt dat vrij is, maar feitelijk niet vrij is, toch opruimen, dan zal je een zogenoemde zerofill moeten uitvoeren. Dat betekend dat je alle vrije ruimte opvult met null data. Het bestand dat gemaakt wordt neemt dan alles in wat vrij is waarna je die kan verwijderen. Omdat het bestand alleen maar nullen bevat, is dat makkelijk te comprimeren.

Iets wat mij wel opvalt, is dat je pas net met Linux bezig bent en je nu al wat geavanceerde zaken wilt gaan doen. Door je gebrek aan kennis loop je van het ene probleem naar het volgende. Niet heel erg, iedereen is ergens begonnen. Maar het is wellicht een beter idee om zelf in een virtuele machine of desnoods de Pi zelf wat aankloot en dingen gaat testen, slopen, proberen te herstellen met hulp van Google om zo meer 'feel', kennis en ervaring van het systeem te krijgen.

Ik ben ondertussen kwijt wat je nou precies met de Pi wilt doen. Want wellicht kunnen we je veel beter een script geven die iets vergelijkbaars doet als dat Domoticz script wat je hebt gevonden.

[andregroeneveld]

ninjazx9r98 schreef op maandag 19 augustus 2019 @ 18:27:
@andregroeneveld
Heb je niet voor niets uitgelegd hoe je die code tags kunt gebruiken
Weet je zeker dat je back-up file gezipt is /wordt?
Met het commando "file <backupfile>" moet je dat kunnen zien. Doe ik dat bij op een gezipte logfile dan zie je dit:

code:

pi@pihole:~ $ file /var/log/syslog.2.gz
/var/log/syslog.2.gz: gzip compressed data, last modified: Sat Aug 17 22:00:01 2019, from Unix, original size 76941

PS
Ik zag je ook schrijven dat je met het ps commando zocht naar cron, denk dat je beter kunt zoeken naar dd of gzip aangezien dat de processen zijn waar je echt naar op zoek bent. Denk ook dat je niet voldoende geduld hebt om af te wachten of de back-up nog loopt en dat zou ook meteen verklaren waarom de temperatuur hoog blijft. De temperatuur blijft hoog omdat de back-up nog loopt maar jij breekt deze af met een reboot en ziet deze vervolgens een stuk lager na het opnieuw booten wat niet zo vreemd is aangezien het proces dat de temperatuur laat oplopen net daarvoor de nek is omgedraaid

@PS zit wat in, zou inderdaad zo gegaan kunnen zijn.
Het bestand is +/- 26 GB groot als ik kijk via WinSCP.

code:

pi@raspberrypi:~ $ file /mnt/usb/raspberrypi.20190820_03.img.zip
/mnt/usb/raspberrypi.20190820_03.img.zip: gzip compressed data, last modified: T    ue Aug 20 02:00:01 2019, from Unix, original size 183777052
pi@raspberrypi:~ $

Hero of Time schreef op maandag 19 augustus 2019 @ 20:24:
Om antwoord te geven op de vraag waarom je backup nu zo groot is, kan je vertellen hoe vol de SD kaart was:

De sd kaart is 64 GB en met SD Formatter eerst geformatteerd, dan houd je nog zo`n 58 GB over.

Als die vol met foto's stond en andere zooi, dan blijft dat er staan. Met dd wordt er een ruwe dump gemaakt. Als je bestanden verwijdert, wordt de verwijzing naar het bestand weggehaald, maar fysiek op de schijf, maar ook dus geheugenkaartjes, staat het er nog. Dat is hoe je met data herstel software je per ongeluk verwijderde document of foto's terug kan halen. Omdat het bestand zelf nog niet weg is of overschreven door andere data.

De sd was helemaal leeg. Zoals het het er nu uitziet is er maar +/- 2,5 GB bezet. Dit kun je zien in een eerder post van mij waar ik het commando df -h gaf.

Dus, als die kaart voor zo'n 50 GB vol heeft gestaan, zal gzip weinig kunnen om het kleiner te maken omdat er eigenlijk gewoon data staat.

Wil je deze ruimte, wat je denkt dat vrij is, maar feitelijk niet vrij is, toch opruimen, dan zal je een zogenoemde zerofill moeten uitvoeren. Dat betekend dat je alle vrije ruimte opvult met null data. Het bestand dat gemaakt wordt neemt dan alles in wat vrij is waarna je die kan verwijderen. Omdat het bestand alleen maar nullen bevat, is dat makkelijk te comprimeren.

Als blijkt dat het zo is dan hoor ik graag hoe ik dit moet doen?

Iets wat mij wel opvalt, is dat je pas net met Linux bezig bent en je nu al wat geavanceerde zaken wilt gaan doen. Door je gebrek aan kennis loop je van het ene probleem naar het volgende. Niet heel erg, iedereen is ergens begonnen. Maar het is wellicht een beter idee om zelf in een virtuele machine of desnoods de Pi zelf wat aankloot en dingen gaat testen, slopen, proberen te herstellen met hulp van Google om zo meer 'feel', kennis en ervaring van het systeem te krijgen.

Je hebt gelijk dat mijn kennis beperkt is ondanks ik al 2 BananaPi`s, een Arduino Mega en een Arduino Micro heb draaien. Mijn 4 satelliet tuners zijn ook unix boxen. Allemaal kennis vergaard via fora. En ik vind het leuk

Ik ben ondertussen kwijt wat je nou precies met de Pi wilt doen. Want wellicht kunnen we je veel beter een script geven die iets vergelijkbaars doet als dat Domoticz script wat je hebt gevonden.

Ik ben door een collega lekker gemaakt met het verhaal van de pi-hole. Dit wou ik ook graag. Op zich was hier uit te komen met een handleiding op dit forum. Uit ervaring weet ik dat de boel corrupt kan raken of vastlopen, noem maar op wat er mis kan gaan. Dus heb ik een back-up van imagen, sd kaartje en bestanden. Dit wil ik ook voor mijn pi-hole. Ik probeerde het eerst via een usb en als dit zou lukken het zelfde trucje toepassen om dit naar mijn nas te doen. Dit was gelukt dacht ik toen de sd kaart stuk ging. De image even terugzetten mislukte. Mogelijk waren de imagen niet goed en of niet BalenaEtcher gebruikt.
Dus wat ik graag zou willen is een back-up nrond 21:00 of zo naar mijn nas schrijven maar dat het niet vastloopt wanneer de nas zich zelf uitzet om 23:00 uur.

[ Voor 0% gewijzigd door Hero of Time op 20-08-2019 20:38 ]

[Freee!!]

andregroeneveld schreef op dinsdag 20 augustus 2019 @ 06:39:
[...]
wanneer de nas zich zelf uitzet om 23:00 uur.

En daar ga je hard de fout in. Die Raspberry Pi moet gewoon 24/7 door draaien. Zoveel stroom gebruikt die echt niet en door het telkens in- en uitschakelen slijten diverse dingen zo hard, dat je de financiële besparing op elektriciteit direct weer meer dan kwijt bent aan die andere dingen, om te beginnen extra SD-kaartjes en tijd.

[andregroeneveld]

Freee!! schreef op dinsdag 20 augustus 2019 @ 12:25:
[...]

En daar ga je hard de fout in. Die Raspberry Pi moet gewoon 24/7 door draaien. Zoveel stroom gebruikt die echt niet en door het telkens in- en uitschakelen slijten diverse dingen zo hard, dat je de financiële besparing op elektriciteit direct weer meer dan kwijt bent aan die andere dingen, om te beginnen extra SD-kaartjes en tijd.

Maar dat moet kunnen zoals je kon zien in dat script die een back-up maakt van domotica op de nas. Hij mount de nas en maakt de back-up en unmount van de nas nadat hij klaar is en de RaspberryPi blijft doordraaien.

[Cyphax]

@andregroeneveld Ik heb de vetgedrukte stukjes in je post even ont-vet; het staat wat schreeuwerig.

[Pierre]

En waarom je de NAS uitzet is me een raadsel?

[Freee!!]

andregroeneveld schreef op dinsdag 20 augustus 2019 @ 14:04:
[...]
Maar dat moet kunnen zoals je kon zien in dat script die een back-up maakt van domotica op de nas. Hij mount de nas en maakt de back-up en unmount van de nas nadat hij klaar is en de RaspberryPi blijft doordraaien.

Je maakt het nodeloos ingewikkeld. Een automount tijdens booten is handig, verder gemount laten.
Er is een reden, dat KISS belangrijk wordt gevonden door experts.

[andregroeneveld]

Pierre schreef op dinsdag 20 augustus 2019 @ 14:32:
En waarom je de NAS uitzet is me een raadsel?

Omdat er 6 x 2T inzit als RAID-5 en best wel wat stroom verbruikt. Hij spint wel down na een bepaalde tijd en verbruikt dan minder. Is ook een keuze.

[Pierre]

andregroeneveld schreef op dinsdag 20 augustus 2019 @ 15:15:
[...]

Omdat er 6 x 2T inzit als RAID-5 en best wel wat stroom verbruikt. Hij spint wel down na een bepaalde tijd en verbruikt dan minder. Is ook een keuze.

Die van mij spint ook down maar ik zet hem nooit uit. Dat is funest voor de harddisks die je gebruikt.

[andregroeneveld]

Pierre schreef op dinsdag 20 augustus 2019 @ 17:14:
[...]

Die van mij spint ook down maar ik zet hem nooit uit. Dat is funest voor de harddisks die je gebruikt.

Dit zit softwarematig ingebakken in deze nas. Hij gaat niet uit zoals misschien gedacht word dat de 230 er af gaat. Elk weekend doet de nas een scrub van de schijven en een schijf controle, ook ingebakken. Nooit iets mee, alles 100%.

[ Voor 10% gewijzigd door andregroeneveld op 20-08-2019 18:02 ]

[andregroeneveld]

Voor iedereen die deze post volgt, de image.zip back-up is ruim 58 GB groot dus precies de hele sd kaart. In de ochtend is deze ongeveer 26 GB groot en dan is hij al vanaf 03:00 uur bezig, aardig tijdje.

De nieuwe sd kaartjes zijn binnen en daar ga ik eens mee kijken of de oude image.zip`s van 4,5 GB goed zijn en de nieuwe grote van 58 GB.

Als ik het grote zip bestand uitpak dan is hij te groot voor op de nieuwe sd kaart. Vreemd, dan is de sd kaart die er in zit net even iets groter dan deze nieuw. Snap ook niet dat het gezipt is wat ook duidelijk te zien was met het commando: file /mnt/usb/raspberrypi.20190820_03.img.zip zo groot is. Dus kan ik het niet eens gebruiken op een andere sd kaart.
Het kleine zip bestand van 4 GB past uiteraard wel.
Even kijken of ik vanavond laat de sd in de RaspberryPi plaats of hij opstart. Ben reuze benieuwd.

[ Voor 68% gewijzigd door andregroeneveld op 20-08-2019 19:22 ]

[Hero of Time]

Met ook je reacties op mijn post in een fatsoenlijke split-quote is het veel prettiger lezen en fatsoenlijk op te reageren.

andregroeneveld schreef op dinsdag 20 augustus 2019 @ 06:39:
[...]

De sd kaart is 64 GB en met SD Formatter eerst geformatteerd, dan houd je nog zo`n 58 GB over.

Dat hoeft nog steeds niet de SD kaart volledig te vullen met nullen. Een quick format is met enkele seconden klaar en haalt eigenlijk alleen de file table leeg door een nieuwe te maken.

[...]

De sd was helemaal leeg. Zoals het het er nu uitziet is er maar +/- 2,5 GB bezet. Dit kun je zien in een eerder post van mij waar ik het commando df -h gaf.

Zoals ik al aangaf, het lijkt leeg, maar is het waarschijnlijk niet. Alsof je huiskamer stampvol mensen staat, maar omdat je gangdeur dicht is, kan je bij de voordeur net doen alsof je huis leeg is qua mensen.

[...]

Als blijkt dat het zo is dan hoor ik graag hoe ik dit moet doen?

Met Google kan je wel wat vinden op de term 'zero fill' die ik gebruikte.

[...]

Ik ben door een collega lekker gemaakt met het verhaal van de pi-hole. Dit wou ik ook graag. Op zich was hier uit te komen met een handleiding op dit forum. Uit ervaring weet ik dat de boel corrupt kan raken of vastlopen, noem maar op wat er mis kan gaan. Dus heb ik een back-up van imagen, sd kaartje en bestanden. Dit wil ik ook voor mijn pi-hole. Ik probeerde het eerst via een usb en als dit zou lukken het zelfde trucje toepassen om dit naar mijn nas te doen. Dit was gelukt dacht ik toen de sd kaart stuk ging. De image even terugzetten mislukte. Mogelijk waren de imagen niet goed en of niet BalenaEtcher gebruikt.
Dus wat ik graag zou willen is een back-up nrond 21:00 of zo naar mijn nas schrijven maar dat het niet vastloopt wanneer de nas zich zelf uitzet om 23:00 uur.

Ah, dus een full image backup is eigenlijk helemaal niet nodig. Het enige wat je moet hebben, is een backup van Pi-hole. Als je die eenmaal hebt ingericht zoals je wilt, zou je handmatig een backup kunnen maken door op de webinterface in te loggen en dan onder Settings -> Teleporter een backup ophalen. Bij mij is die 2,3 KB. Veel vriendelijker voor je schijfruimte dan de 58 GB die een dd image omvat. En dat is vele malen sneller opnieuw op te zetten. Het enig wat je hoeft te doen is een nieuwe Raspbian image op een SD kaart zetten, de installer van Pi-hole draaien en dan de Teleporter backup uploaden.

Zie ook https://www.reddit.com/r/...qeu/backup_pihole_config/ met het vervolg op de vraag. Daar wordt gesteld dat je dit via een script kan draaien:

pihole -a -t

Dat maakt een tar.gz bestand aan, zoals je dat via de webinterface zou krijgen, met een timestamp.

Als je dus je NAS 24/7 aan laat staan, kan je dat commando in een cronjob zetten waarbij je eerst naar je NAS mount point gaat. Tijd en datum zelf invullen, als commando doe je dan dit:

cd /mnt/nas && pihole -a -t

Klaar, geen omkijken meer naar behalve dan zorgen dat je NAS aan staat.

Andere optie is om je mount point in fstab te zetten met de optie 'noauto' zodat deze niet bij het opstarten wordt gemount en dan een simpel script maken dat 'm mount (gewoon mount /mnt/nas), een controle doet dat het gekoppeld is (bijvoorbeeld door te controleren of een specifiek bestand bestaat in je mount point), het pihole commando uitvoeren en dan een umount /mnt/nas doen.

Is je Pi gaar, dan kan je op elk systeem waar Pi-Hole op kan draaien zo de boel herstellen. Gaat je Pi zelf stuk, dan heb je ook niet het probleem dat je echt, absoluut, zonder andere optie, dezelfde model Pi moet hebben omdat de backup anders mogelijk niet werkt.

[andregroeneveld]

Bedankt voor de uitleg Hero of Time, ik ga het eens bestuderen want liep toch weer tegen wat problemen op.

De test van de image van het kleine zip bestand 4 GB die werkte. Ik moest wel even de veiligheidskey opnieuw accepteren met putty maar ik kon er in en ook met WinSCP alles benaderen. Ik had alleen geen webinterface meer van pi-hole en ook geen internet meer omdat alles via de pi-hole liep. Hier kwam ik één, twee, drie niet achter waarom?
Toen heb ik de sd kaart die er in zat weer teruggezet. En niet meer werken???? Niet meer benaderbaar via putty alleen een basale ping. Omdat ik naar mijn werk moest had ik geen tijd meer om verder te kijken.

[ Voor 10% gewijzigd door andregroeneveld op 21-08-2019 07:35 ]

[Hero of Time]

Het niet werken als je de vorige, wel werkende, kaart erin doet is vreemd. Dat zou niet moeten tenzij er bepaalde zaken niet geladen kunnen worden door fouten op het systeem. Met een scherm eraan kan je meer zien wat er gebeurt.

Voor wat betreft het terugzetten van de backup dat daardoor de webinterface e.d. niet meer werkte, dat komt zeer waarschijnlijk door lock bestanden. Die worden in de backup meegenomen, want je maakt immers een 'snapshot' van een nog draaiend systeem. Services zoals dnsmasq (wat Pi-Hole gebruikt) maken bestanden aan om bij te houden en aan te geven dat het draait. Als deze bestanden nog bestaan als het proces zelf eigenlijk niet meer draait, zal het bij het opstarten deze vinden en weigeren te starten.
Daar is bij het maken van de backup niet over nagedacht dat dit gebeurt. Nog een reden om een simpelere methode te gebruiken voor backups.

[andregroeneveld]

Hero of Time schreef op woensdag 21 augustus 2019 @ 08:01:
Het niet werken als je de vorige, wel werkende, kaart erin doet is vreemd. Dat zou niet moeten tenzij er bepaalde zaken niet geladen kunnen worden door fouten op het systeem. Met een scherm eraan kan je meer zien wat er gebeurt.

Voor wat betreft het terugzetten van de backup dat daardoor de webinterface e.d. niet meer werkte, dat komt zeer waarschijnlijk door lock bestanden. Die worden in de backup meegenomen, want je maakt immers een 'snapshot' van een nog draaiend systeem. Services zoals dnsmasq (wat Pi-Hole gebruikt) maken bestanden aan om bij te houden en aan te geven dat het draait. Als deze bestanden nog bestaan als het proces zelf eigenlijk niet meer draait, zal het bij het opstarten deze vinden en weigeren te starten.
Daar is bij het maken van de backup niet over nagedacht dat dit gebeurt. Nog een reden om een simpelere methode te gebruiken voor backups.

Ik denk dat ik mij toch meer ga verdiepen in die simpelere methode. Vanavond de boel opnieuw installeren op een nieuw beter sd kaartje. Ik heb nog wel via teleporter een backup gemaakt zoals je laatst aangaf. Gaat deze dan wel werken als ik die terugzet wanneer ik Pi-Hole weer heb geïnstalleerd?

[Hero of Time]

Dat is het hele idee van Teleporter. Je maakt daarmee een backup van je configuratie in Pi-Hole om die op welk ander systeem weer in te laden. Dat kan dus ook een nieuwe installatie op hetzelfde apparaat zijn.

[andregroeneveld]

Hero of Time schreef op woensdag 21 augustus 2019 @ 18:41:
Dat is het hele idee van Teleporter. Je maakt daarmee een backup van je configuratie in Pi-Hole om die op welk ander systeem weer in te laden. Dat kan dus ook een nieuwe installatie op hetzelfde apparaat zijn.

Dat lijkt mij ideaal alleen wil de RaspberryPi niet meer op starten. Nieuwe sd geformatteerd (niet snel) en de 2019-07-10-raspbian-buster-lite.image er op gezet maar niet starten zo lijkt het. De vorige imagen kunnen toch niet de RasberryPi stuk maken?

[Hero of Time]

Je moet aardig wat doen om een Pi te slopen eigenlijk. Heb je wel beeld? Want dan kan je zien wat er eventueel mis is. Nu is het meer een gevalletje 'zit de stekker er wel in', want onze glazen bol doet 't ook niet.

[andregroeneveld]

Hero of Time schreef op woensdag 21 augustus 2019 @ 19:16:
Je moet aardig wat doen om een Pi te slopen eigenlijk. Heb je wel beeld? Want dan kan je zien wat er eventueel mis is. Nu is het meer een gevalletje 'zit de stekker er wel in', want onze glazen bol doet 't ook niet.

Ik heb geen monitor HDMI naar de TV toe. USB dongle voor muis. Moet dat lukken?
Geen beeld helaas!

[ Voor 9% gewijzigd door andregroeneveld op 21-08-2019 19:51 ]

[andregroeneveld]

Ik denk dat ik het gevonden heb. Het kaartslot is rot. Hij maakt slecht contact. Dit is dus veroorzaker van alle ellende die ik steeds heb met dat het systeem vastloopt en niet doet wat je er van verwacht. Ik ga hem terug sturen. Balen zeg. Nu snap ik dat die sd kaartjes zo snel stuk gingen. Het NOOB sd kaartje ging stuk en een eigen sd kaart. Ik krijg hem opgestart als ik de sd kaart omhoog druk en vasthoud. Hij gaat retour BOL.

[ Voor 28% gewijzigd door andregroeneveld op 24-08-2019 07:27 ]

[Hero of Time]

Ook bovenstaande had je samen kunnen voegen in een enkele post.

Jammer, maar gelukkig heb je het probleem gevonden. En een TV met HDMI doet ook wat het moet doen als monitor: beeld geven. Want je wilt zien wat het doet.

[andregroeneveld]

Zo, het heeft even geduurd maar sinds gisterenavond draait de Pi-Hole weer. Ik had een complete RasberryPi 3B + set met heatsinks en ventilator en hdmi kabel gekocht voor 63,- incl. verzenden en dat duurde even voordat het binnen was.
Ik moet weer even alles doorlezen om een backup in te stellen en te maken.

[ Voor 13% gewijzigd door andregroeneveld op 07-09-2019 20:51 ]

[andregroeneveld]

Als eerste maar weer volgens beschrijving een back-up gemaakt van de sd kaart. Dit lukt eerst niet nu wel
19.Backup your Pi-hole.
Once you have a working pi-hole, you can avoid setting it all up again by creating an image of your system.
Shutdown your system
sudo poweroff
Remove the SD card from the Raspberry Pi.
Use Win32DiskImager to create an image
- Insert the SD card into your computer.
- Start Win32DiskImager.
- Image File: Select a location and name for the image, e.g. C:\temp\pi-hole.img
- Device: Select the drive, holding the SD card, multiple partitions (drives) exist on the SD card, select the first one (all partitions will be processed).
- Select Read
Wait…
Whenever you restore (use etcher) the backup image, the first thing you should do is set the date and time and restart the NTP service. If you are using ‘systemd-timesyncd.service’, the systems default NTP service, this might be done automatically (never tested). If you have opted for the more robust NTP daemon, you need to do this manually, because the NTP daemon only allows for small time corrections, this to avoid large adjustments from an incorrect time source.

[andregroeneveld]

Ik wil nog een keer verder gaan om een automatische back-up te maken of d.m.v. commando wanneer ik dat zelf wil uitvoeren.
Helaas is mijn lieve vrouw recent overleden en ben ik niet in staat om dingen goed te doen. Dit verklaart ook dat ik in mijn topic mijn hoofd er niet goed bij had

[Freee!!]

andregroeneveld schreef op maandag 28 oktober 2019 @ 07:29:
Ik wil nog een keer verder gaan om een automatische back-up te maken of d.m.v. commando wanneer ik dat zelf wil uitvoeren.
Helaas is mijn lieve vrouw recent overleden en ben ik niet in staat om dingen goed te doen. Dit verklaart ook dat ik in mijn topic mijn hoofd er niet goed bij had

Gecondoleerd.