Voorkom een corrupte Micro SD-kaart in de Raspberry Pi

Als je al wat ervaring met een Raspberry Pi (i.c.m. Domoticz) hebt dan weet je dat de Micro SD-kaart nogal wat te lijden heeft vanwege de vele schrijf-acties door het operating system op de MicroSD kaart. Veel applicaties schrijven veelvuldig hun logbestand weg naar de Micro SD-kaart. Wat denk je van Domoticz? Indien je wat meer sensoren en switches heb dan wordt er zowat iedere seconde wel iets weggeschreven. Gelukkig is daar een oplossing voor: Log2Ram. Deze applicatie kan er voor zorgen dat log-data naar RAM wordt weggeschreven. Ieder uur (en als de Raspberry Pi op een normale wijze uitgezet wordt) dan worden de log-bestanden vanuit RAM naar de MicroSD kaart weggeschreven. Dit betekent 99,9% minder schrijfacties op de geheugenkaart!

Benodigdheden

Log-bestanden Raspbian

Haal de installatie van de GitHub-repository:


Ken de juiste rechten toe aan het script:


Start het installatie-scripts:


Verwijder de installatie-bestanden:


Herstart de Raspberry Pi:


Standaard schrijft Log2Ram ieder uur de data naar de geheugenkaart. Mocht je van mening zijn dat dit te vaak is dan kun je dit aanpassen door het dagelijks weg te schrijven. Het cron-bestand verplaatsen we dan van uurlijks naar dagelijks:


Controleer na de reboot of alles goed gegaan is:


 

Tijdelijke bestanden Domoticz

De volgende stap is om de tijdelijke bestanden die Domoticz nodig heeft te verplaatsen naar RAM:


Voeg onderstaande regel toe:


Ik heb er voor gekozen om een 100 Mb RAM-drive aan te maken, maar 25 of 50 Mb moet doorgaans ook voldoende zijn.

Sla het bestand op en mount de RAM-drive:


Controleer of alles goed gegaan is:


Stop Domoticz en pas het /etc/init.d/domotic.sh bestand aan:


Zoek nu #DAEMON_ARGS="$DAEMON_ARGS -log /tmp/domoticz.txt" in het bestand. Wijzig deze regel naar DAEMON_ARGS="$DAEMON_ARGS -log /tmp/log/domoticz.log -loglevel=normal". Vergeet niet het #-teken weg te halen!

Voeg nu regel 6 t/m 9 toe, zoals in onderstaand voorbeeld:


Sla de wijzigingen op en sluit de editor.

Optioneel kun je ook de Z-wave log naar de RAM-drive verplaatsen:


Herstart Domoticz:


Het kan zijn dat er gevraagd wordt om een systemctl daemon-reload te doen:


Je zou nu alle relevante bestanden in de /tmp/log/ directory moeten zien… Hier is een voorbeeld:


 

31 gedachten over “Voorkom een corrupte Micro SD-kaart in de Raspberry Pi

  • 25 februari 2019 om 22:22
    Permalink

    Ook deze toevoeging succesvol kunnen uitrollen op mijn pi. Dank!

    Beantwoorden
  • 5 april 2019 om 20:14
    Permalink

    Ik zie regelmatig (met de raspi check app) dat /tmp/log op 100% zit. Ik heb deze ingesteld op 100 Mb. Ik kan deze wel vergroten maar vraag me af of het goed is dat deze telkens vol zit? Domoticz vertoont geen problemen.

    Beantwoorden
    • 5 april 2019 om 15:44
      Permalink

      Rens, er staat ook een artikel online, waarin uitgelegd staat hoe je iedere dag het logbestand weg kunt schrijven, zodat het tijdelijke bestand weer leeg is, dan kom je nooit aan 100 Mb (of je moet heeeeel veel loggen).

      Beantwoorden
  • 26 juli 2019 om 12:06
    Permalink

    Super duidelijke tutorial mijn dank hiervoor.

    Beantwoorden
  • 13 oktober 2019 om 11:11
    Permalink

    Hmmmmmm,
    Krijg nu ieder uur de volgende error boodschap:

    Error: SQL Query(“VACUUM”) : database or disk is full

    Enig idee hoe dit is te verhelpen?

    Gr Harald

    Beantwoorden
    • 13 oktober 2019 om 20:16
      Permalink

      Waarschijnlijk is één van de bestanden die je naar de log2ram of tmpfs volume wilt schrijven te groot (of het volume te klein).

      Beantwoorden
  • 16 november 2019 om 13:54
    Permalink

    Allereerst bedankt voor al je info.
    Heb al een aantal van je oplossingen gevolgd waaronder nu ook deze.

    Na alle instructies meerdere malen nagelopen te hebben, en volgende te zien

    Filesystem Size Used Avail Use% Mounted on
    log2ram 128M 4.4M 124M 4% /var/log
    tmpfs 93M 0 93M 0% /run/user/1000
    wat er voor mij wel goed uit ziet.

    Alleen de 0% snap ik niet helemaal.

    Ook in het Log (log -l) krijg ik als resultaat “total 0”

    Doe ik nu iets fout?

    mvg

    Beantwoorden
  • 6 februari 2020 om 11:13
    Permalink

    Alles ging goedmet de installatie enkel:
    sudo mv /etc/cron.hourly/log2ram /etc/cron.daily/log2ram

    werkt niet. Kon het bestand niet vinden…

    groet

    Beantwoorden
  • 18 februari 2020 om 16:29
    Permalink

    Ik heb alle stappen netjes doorlopen en werkt naar behoren.

    Echter nu laat Domoticz de data van 1 dag terug maar zien. Hoe kan ik dit aanpassen, zodat deze ook weer de geschiedenis in beeld brengt.

    Beantwoorden
  • 12 maart 2020 om 21:09
    Permalink

    Na de reboot startte mijn RPi niet meer. Pas nadat ik weer een monitor op HDMI had aangesloten ging het opstarten weer goed. Dus dat was heel even schrikken. Nu is alles weer prima en loggen naar RAM werkt goed. Bedankt!

    Beantwoorden
  • 24 maart 2020 om 16:34
    Permalink

    Super uitleg! Heb een tijdje hier mee gedraaid.

    Pas alleen op als je Domoticz 2020.1 gaat draaien!! Dan werkt dit helaas niet meer, aangezien de nieuwe versie van SQlite geen snelkoppeling toestaat.

    Ik heb helaas dus deze super tip, moeten uitschakelen. Tijd voor mij om een SSD te gaan zoeken voor de Rasp 4

    Beantwoorden
    • 24 maart 2020 om 20:41
      Permalink

      Ik had dit probleem ook, domoticz bijgewerkt maar daarna werkte deze niet meer, waarschijnlijk vanwege hetgeen jij beschrijft, met snelkoppeling bedoel je de symlink?

      Is er geen andere mogelijkheid om dit alsnog weer te laten werken icm de laatste domoticz versie?

      Beantwoorden
      • 25 maart 2020 om 17:36
        Permalink

        Hallo Rens,

        Inderdaad dat zijn de “symlinks”.
        Er is op dit moment helaas nog geen andere “workaround”. Dus ben al een beetje om me heen aan het kijken voor een SSD.

        Beantwoorden
      • 25 maart 2020 om 22:34
        Permalink

        Ik heb die symlinks weggehaald en draai nu mijn database volledig op de log2ram schijf.
        1. stop Domoticz met: sudo systemctl stop domoticz
        2. wijzig het script: sudo nano /etc/init.d/domoticz.sh
        zet een # voor de 2 regels die de links maken (# ln -sf /log/…..)
        voeg bovenin deze regel toe:
        DAEMON_ARGS=”$DAEMON_ARGS -dbase /var/log/domoticz/domoticz.db”
        3. Kopieer je database naar de nieuwe locatie: sudo cp /home/pi/domoticz/domoticz.db /var/log/domoticz/domoticz.db
        4 start domoticz weer: sudo systemctl start domoticz

        Beantwoorden
        • 26 maart 2020 om 17:19
          Permalink

          Hallo Maarten,

          Dit zet alleen de database in de Log2ram. En natuurlijk zijn er wat schrijven bewegingen in de database. Maar de bestanden die door SQLite worden gebruikt, worden bijna elke seconde weg geschreven. En die gaan volgens mij niet mee jou aanpassing.

          Beantwoorden
          • 26 maart 2020 om 22:25
            Permalink

            Hi Marco,

            Bij mij zijn de domoticz.db-shm en domoticz.db-wal bestanden hierdoor ook meeverhuisd naar /var/log/domoticz. Zijn er nog andere bestanden?

          • 27 maart 2020 om 17:33
            Permalink

            Hey Maarten,

            Nee die 2 bestanden van SQLite zijn de grootste schrijvers. Heb het even geprobeerd op de manier zoals jij beschrijft. Misschien dat ik iets verkeerds doe, maar zoals ik nu zag, schrijft hij de 2 bestanden van SQLite (-wal en -shm) eerst gewoon in de Domoticz dir (dus op de SD kaart) en bij herstart/afsluiten van Domoticz schrijft hij ze pas weg met Ramlog (of elk uur/dag).

            En in de “oude” situatie, blijf hij ze wegschrijven in de RAM, zodat je minimale schrijf “bewegingen” op je SD hebt.

        • 28 maart 2020 om 13:41
          Permalink

          Het gewenste (alle 3 de bestanden in /var/log/domoticz) resultaat krijg je ” vervangt door ” in stap 2. Dus DAEMON_ARGS=”$DAEMON_ARGS -dbase /var/log/domoticz/domoticz.db”
          Controle: ps -ef uitvoeren en controleren dat het -dbase argument mee is gekomen.

          Beantwoorden
          • 28 maart 2020 om 13:44
            Permalink

            De reactie wordt blijkbaar aangepast. De double quotes kun je niet copy paste gebruiken.
            Met de hand aanpassen. In de reacties worden de normale double quotes door vervangen, en dat wordt door de sh niet begrepen.

          • 31 maart 2020 om 20:24
            Permalink

            Ik heb met deze info nu ook alle drie de bestanden in /var/log/domoticz/ staan, en er wordt dagelijks naar de geheugenkaart weggeschreven (/etc/cron.daily/log2ram).

            Ik maak iedere nacht om 03.00u een backup naar mijn nas (via instructie ‘Automatische Raspberry Pi backup – complete image’). Vooraf wordt hierin de domoticz service gestopt en na afloop weer gestart.

            Gaat het dan wel goed met het meenemen van de database in de backup als deze op dat moment in log2ram staat? Ik wil natuurlijk nog wel een correcte en volledige backupfile hebben in de nacht.

          • 2 april 2020 om 16:48
            Permalink

            Duidelijk Johan,

            Ik vind het persoonlijk wel erg link om ook de database mee te nemen in de Ramdisk. Als de spanning wegvalt, of de PI loopt vast, dan is je de database ook weg. Nu is dit op te vangen om met een script 1x in de zoveel tijd een backup te maken van de database. Maar het is mij te riskant. Dus ben al om me heen aan het kijken om een goedkope SSD aan te schaffen.

  • 7 april 2020 om 11:43
    Permalink

    Bij mij werkt het helaas ook niet meer sinds Domoticz 2020.1.

    Hoe werkt dat met een SSD? Kan je de volledige SD kaart vervangen door een SSD?

    Beantwoorden
    • 7 april 2020 om 19:08
      Permalink

      Dat ligt aan de type Pi die je hebt. T/m Pi3B kan je starten vanaf SSD.

      Bij de Pi4 is dat nog niet mogelijk helaas. Daar is het opstarten vanaf SD en de rest vanaf SSD

      Beantwoorden
      • 8 april 2020 om 09:14
        Permalink

        Thx Marco.
        Komt goed uit, ik heb een 3B.
        Kan ik dan gewoon de SD clonen naar een SSD en dan ben ik klaar? Ik kan er (nog) niet hele duidelijke info over vinden.

        Beantwoorden
  • 9 juni 2020 om 14:18
    Permalink

    Die van USB 3.0 op de USB2.0 poort had ik nog niet gezien. Maar het hele gebeuren om m’n PI3B te laten starten vanaf een SSD was mij niet gelukt: 3x de complete setup doorlopen, na uiteraard eerst images van de SD en een kloon van de daarvoor gebruikte HDD te hebben gemaakt (had die dus vaker nodig). Groene lampje komt niet op, zelf dacht ik aan te trage SSD want kon geen duidelijke reden vinden.
    Wat ik gebruik is een Samsung 840 SSD in een USB 3.0 enclosure, dus wellicht is dat dan de oorzaak. Alleen Bart krijgt het blijkbaar wel draaiend op een USB 3.0, bij mij boot het dus niet eens. Apart, werd er wat simpel van. Wil nu nog Domoticz direct op de SSD laten werken, nog even zoeken hoe.

    Beantwoorden
    • 23 juni 2020 om 21:17
      Permalink

      Hoi Jan,

      Ik heb het met veel pijn en moeite wel draaiend gekregen ja, maar niet voor lang. Na een tijdje werkt de SSD ineens niet meer (oa bovenstaande foutmelding).
      Dus hij draait ‘gewoon’ weer op de oude SD kaart. Ik gebruikt ook een oude SSD maar dat moet volgens mij niet uitmaken. Misschien krijgt ie via de RPI toch te weinig stroom ofzo….
      Mocht iemand een tip hebben dan hoor ik het nog steeds graag.

      Beantwoorden
  • 23 juni 2020 om 10:03
    Permalink

    Ik denk niet dat het een te trage ssd is. Ik draai het inmiddels op een oude laptop HDD via een goedkoop sata naar usb kabeltje en dat gaat prima. Ik gebruik wel een andere techniek: ik heb alleen mijn root gemount op mijn HDD. Dit dus: https://www.raspberrypi.org/forums/viewtopic.php?t=44177. Daarmee heb je nog wel een sd kaartje nodig waarvan hij boot. Maar daarna staan alle files (je root) op je HDD/SDD. Vergeet niet in je backupscript (als je dat gebruikt) de juiste partitie te backuppen. Dus niet meer de /dev/mmcblk0 maar de /dev/sda1 (of welke het dan ook is bij jou).

    Het nadeel van de hele database in log2ram was dat na iedere reboot / stroomuitval mijn database corrupt was en ik weer eerst een backup moest terugzetten. Ik draai nu dus weer zonder log2ram.

    Beantwoorden

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *