bakckups al tijd corrupt...

[newtech2015]

hoi,

gisteravond, toen ik update 2.3.0 wilde uitvoeren, kwam ik erachter dat ik niet meer kon inloggen op mn pi3, uiteindelijk backup van sd kaartje terug gezet.
uitvoeren van de update ging goed, kwam er vervolgens wel achter dat de backups die hij in drobbox zet al > 1 week 1kb groot waren, dus waardeloos.
tja, helaas, stuk history kwijt.

natuurlijk wel nu gekeken, of de backup nu wel werkt:
file in dropper weer 1kb! oeps!

nu met de hand een backup gemaakt, en krijg ik:
root@raspberrypi:~# cd /home/dsmr/dsmr-reader/dsmrreader/provisioning/postgresql
root@raspberrypi:/home/dsmr/dsmr-reader/dsmrreader/provisioning/postgresql# bash psql-backup.sh
--- Dumping backup of 'dsmrreader' to: /data/backup-postgres-Saturday.sql.gz
pg_dump: last built-in OID is 16383
pg_dump: reading extensions
pg_dump: identifying extension members
pg_dump: reading schemas
pg_dump: reading user-defined tables
pg_dump: reading user-defined functions
pg_dump: reading user-defined types
pg_dump: reading procedural languages
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined access methods
pg_dump: reading user-defined operator classes
pg_dump: reading user-defined operator families
pg_dump: reading user-defined text search parsers
pg_dump: reading user-defined text search templates
pg_dump: reading user-defined text search dictionaries
pg_dump: reading user-defined text search configurations
pg_dump: reading user-defined foreign-data wrappers
pg_dump: reading user-defined foreign servers
pg_dump: reading default privileges
pg_dump: reading user-defined collations
pg_dump: reading user-defined conversions
pg_dump: reading type casts
pg_dump: reading transforms
pg_dump: reading table inheritance information
pg_dump: reading event triggers
pg_dump: [archiver (db)] query failed: ERROR: invalid page in block 0 of relati on base/17141/3467
pg_dump: [archiver (db)] query was: SELECT e.tableoid, e.oid, evtname, evtenable d, evtevent, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = evtowner) AS e vtowner, array_to_string(array(select quote_literal(x) from unnest(evttags) as t(x)), ', ') as evttags, e.evtfoid::regproc as evtfname FROM pg_event_trigger e ORDER BY e.oid
-rw-r--r-- 1 root root 20 Sep 14 12:06 /data/backup-postgres-Saturday.sql.gz

het Sd kaartje zal wel ergens corrupt zijn geraakt, dat valt nutuurlijk wel weer op te lossen.
Maar, is er iets te doen, dat je een melding, bv mail krijgt, dat als de backup onrealistisch klein is, dat je dan gewaarschuwd wordt?

kom hier verder dan 1 week later achter.. dan heb je niks meer om op terug te vallen, en ben je alles kwijt!

[newtech2015]

oa ja... voor ik het vergeet... hoe kan ik nu toch nog history gegevens eruit halen, zal een ouder image op het sd kaartje moeten gaan zetten, of mss een hele nieuwe installatie, maar dan ben ik nog meer of zelfs alle history data kwijt, damn!

[dennissiemensma]

Bedankt voor je melding. Ik heb helaas slechts zeer recent wat hiervoor kunnen doorvoeren. In de laatste of een na laatste versie maakt de applicatie een extra backup (alleen dagtotalen) in een submap, die ook naar Dropbox gesynchroniseerd wordt.
De bestanden in die submap worden niet geroteerd om het issue, waar je nu tegenaan loopt, te voorkomen.

Als extra zou je ook nog ervoor kunnen kiezen om elke week, twee weken of maand een backup te sturen naar een GMail-adres.

[dennissiemensma]

Wat betreft je vraag over hoe je je gegevens kan terughalen, in hoeverre heb je nu alsnog een backup? Of alleen een oude image?

[newtech2015]

hoi, tja.. ben er gisteren letterlijk de hele dag mee bezig geweest.De sd kaart die erin zat, is niet meer goed. Vervelend hiervan, is dat je er niets van merkte.. keek meerdere keren per week op de web-pagina van dsmr, en t werkte gewoon, inclusief totalen van de afgelopen dagen, maanden enz. Maar, t kon niet meer gebackupt worden, en dat zat er al heel lang in.helaas heb ik al die tijd nooit in de map van droppox gekenen, en niet in de gaten gehad, dat die backups niet goed waren. alle backups die op droppox staan, zijn 1kb, en waardeloos.t enige wat ik nog werkend heb, is een oud sd-kaart image van 1 juli, daarna is alles weg.Een recenter sd-kaart image heeft de fout ook al, en werkt op zich wel.. maar wil je er een backup uithalen of erin zetten, dan gaat dat gewoon niet. baal als een stekker uiteraard, en realiseer me nu dan ook dat dit denk ik, geen los staand incident is.ik werk al sinds de pi-1, met allerlei pi-versies inckusief orange en banana-pi en heb zoiets nog nooit aan de hand gehad.Neem aan dat dit waarschijnlijk komt door het grote aantal lees en schrijf acties op de sd kaart. Denk er dan ook over na, of ik misschien beter een extrene hdd ofzo kan nemen, om dit in de toekomst te voorkomen.Al zou ik t ook heel fijn vinden, als je iets inbouwd, dat je een melding krijgt wanneer een backups, die zoals in t voorbeeld in 1e medling van gisteren in een error eindigen. Want.. als je dit regelmatig gebeurt, en je hele tijden in je metingen mist.. dan heeft t eigenlijk geen zin meer om de meterstanden constant te zitten uitlezen. T is echt een mooi programma, dsmr, en wil t ook graag blijven gebruiken, maar na vrij korte tijd gebruik t pas een paar maanden, en nu dit, geeft me toch de indruk dat dit niet goed geregeld is. groeten, ron

[dennissiemensma]

Dat is zeer spijtig om te horen. Je hebt gelijk dat het ligt aan de hoeveelheid schrijfacties. De SD-kaartjes zijn niet gemaakt voor dit doel en daarnaast zeer onbetrouwbaar. Corruptie in het bestandsysteem is ontzettend moeilijk om mee om te gaan. Dat is iets waar ik nooit een oplossing voor heb gevonden en waarschijnlijk ook niet ga vinden.

Ik zal op termijn kijken naar meer verbeteringen. Ik ben het met je eens dat er nog wel wat extra checks bij kunnen.

Voor nu kan ik je alleen adviseren:

• Als je een DSMRv5 meter hebt, kun je overwegen om niet elke meting te laten loggen. Je kunt DSMRREADER_DATALOGGER_SLEEP op 10 zetten (https://dsmr-reader.readthedocs.io/nl/latest/settings.html#dsmrreader-datalogger-sleep)

• In de latere versies van DSMR-reader worden ook extra backups gemaakt voor dropbox, die niet geroteerd worden.

• Je kunt overwegen om backups van dagtotalen naar een GMail-adres te laten sturen.

[dennissiemensma]

Ik zal de documentatie bijwerken om deze issues wat beter te belichten.

Mocht je inhoudelijk nog hulp nodig hebben met het restoren van de data die je nog hebt, dan hoor ik het graag! Je kunt gewoon de oude data in een nieuwe installatie importeren. Het uitvoeren van het post-deploy-script zorgt er dan voor dat alle versie-verschillen automatisch doorgevoerd worden in de database.

[dennissiemensma]

Ik bedacht me trouwens nog dat Dropbox bestandsgeschiedenis bijhoudt. Je zou daar nog even kunnen kijken of je nog een oudere versie kan terughalen van een van je backups.

[newtech2015]

Daar had ik ook op gehoopt..., maar backups zijn al zo lang slecht, dat er geen goede meet in staat, ook niet in historie Helaas, ben sinds 1 juli, alles kwijt aan data Verzonden via Yahoo Mail op Android Op ma, sep. 16, 2019 om 19:32 schreef Dennis Siemensma<notifications@github.com>: Ik bedacht me trouwens nog dat Dropbox bestandsgeschiedenis bijhoudt. Je zou daar nog even kunnen kijken of je nog een oudere versie kan terughalen van een van je backups. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[newtech2015]

dennis, ik ben toch nog eens goed in de hostory opslag van dropbox gedoken (nog bedankt, voor de tip!), en heb toch nog een goede backkup van 23-8 kunnen redden.(na deze datum waren geen goede backuos meer, dus dat deel ben ik echt kwijt) Deze backup, had een formaat van ongeveer 13,5 Mb Vervolgens heb ik een sd-kaart backup image op een nieuw sd-kaartje gezet. dit was dsmr versie 2.1.pi gestart en die backup terug gezet.Vervolgensdmsr geupdate naar versie 2.3. afgelopen nacht heeft dsmr ie voor t eerst weer een nieuwe backup gemaakt, vond deze wel erg klein, 2Mb.zojuist via putty een gemaakt met: cd /home/dsmr/dsmr-reader/dsmrreader/provisioning/postgresql bash psql-backup.sh nu kwam er een backup uit van zo'n 3,7Mb... zonder errors, dus, lijkt ok. Maar, dat t nu van 13,5 Mb naar 2 of 3,7Mb gaat... vind ik toch wel erg raar... kan dit, ligt dit aan het updaten, of kan is dit een indicatie dat er iets niet klopt?  groeten, ron backup

[dennissiemensma]

• Wat zijn de namen van de bestanden?
• Kan het zijn dat de een gecomprimeerd is en de andere niet?

In een van de meest recent DSMR-reader versies heb ik comprimeren 'verplicht' gemaakt. Het is geen optionele keuze meer.

[newtech2015]

de eerder backup:dsmrreader-postgresql-backup-Wednesday.sql.gz (13,7 Mb) de automatisch gemaakte backup van afgelopen nacht:dsmrreader-postgresql-backup-Wednesday.sql.gz (2 Mb) de handmatige backup:backup-postgres-Wednesday.sql.gz (3,7 Mb) extensie is gelijk, neem aan dat t dan zelfde formaat is ook... raar dat t dan opeens zoveel minder data is

[dennissiemensma]

• Kreeg je bij het terugzetten van de backup verder geen fouten?
• Heb je toevallig retentie aanstaan in de applicatie, waardoor die oude data na een tijdje opschoont?

[newtech2015]

ja, dat staat wel aan, op stand dat ie de meeste gegevens na 1mnd weg doet... kan dat zoveel uitmaken?

[dennissiemensma]

Ik zou niet verwachten dat het zoveel zou uitmaken, maar het kan een factor zijn. Helemaal als je een DSMRv5 slimme meter hebt.

Wat je nog kunt doen is de grotere backup in een tijdelijke database importeren en vervolgens kijken waar het verschil in grootte zit (welke tabellen). Dat is vrij makkelijk te zien met 1 query per database.

Laat maar weten als je dat wilt proberen.

[newtech2015]

hoi, heb inderdaad een DSMRv5 meter. ja, wil dat wel proberen,alleen niet meer vandaag wat ik ook nog wel wil weten, kon ik zo even niet vinden:vanaf 2.3 wordt een ook een backup met alleen dag statistieken gemaakt... gezien ik voorlopig nog wel zal bezig zijn, met zaken proberen, en evt over te stappen op bv een pi4 (werkt dit overigens?)...lijkt me dit handig om de grote backup na een nw install eerst terug te zetten en daarna de kleinere voor de data van de  afgelopen dag(en).. of is dit zo niet de bedoeling?

[dennissiemensma]

wat ik ook nog wel wil weten, kon ik zo even niet vinden:vanaf 2.3 wordt een ook een backup met alleen dag statistieken gemaakt...

Waarschijnlijk komt er morgen een nieuwe versie van dsmr-reader. Hier zitten ook wat betere checks in voor backup's, al zal ik dat nooit helemaal goed krijgen. De backup voor dagstatistieken is alleen bedoeld als absolute nood wanneer de gewone backups niet werken (zoals in jouw geval). Ik raad je niet aan deze te gebruiken als je een gewone backup kan gebruiken.

lijkt me dit handig om de grote backup na een nw install eerst terug te zetten en daarna de kleinere voor de data van de afgelopen dag(en).. of is dit zo niet de bedoeling?

Je kunt die andere, grotere backup gewoon parallel in een aparte tijdelijke database op je Pi importeren. Daar hoeft je productie-database niet onder te lijden. Na afloop kun je de tijdelijke database weggooien.

en evt over te stappen op bv een pi4 (werkt dit overigens?)

Toevallig heb ik vanavond dsmr-reader op een Pi 4 geinstalleerd en dat ging goed.

[dennissiemensma]

Tijdelijke database aanmaken:

sudo sudo -u postgres createdb -O dsmrreader tijdelijke_dsmr_db

Database dump importeren in tijdelijke DB.

• Dit gaat net zoals je al eerder hebt gedaan. Alleen geef je een andere database-naam op:
• Zie het verschil hieronder. De onderste is goed voor tijdelijk.

zcat <PATH-TO-POSTGRESQL-BACKUP.sql.gz> | sudo sudo -u postgres psql dsmrreader
# Wordt
zcat <PATH-TO-POSTGRESQL-BACKUP.sql.gz> | sudo sudo -u postgres psql tijdelijke_dsmr_db

Grootte tijdelijke-database tabellen opzoeken:

sudo sudo -u postgres psql tijdelijke_dsmr_db

# Voer deze query uit.
SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
  FROM pg_class C
  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema')
    AND C.relkind <> 'i'
    AND nspname !~ '^pg_toast'
  ORDER BY pg_total_relation_size(C.oid) DESC
  LIMIT 20;

# Bewaar het resultaat

# Druk een paar keer op CTRL + D om weer uit de database te gaan.

Tijdelijke DB verwijderen

# GOED CONTROLEREN DAT JE NIET PRODUCTIE WEGGOOIT!
sudo sudo -u postgres dropdb tijdelijke_dsmr_db

Grootte productie-database tabellen opzoeken:

sudo sudo -u postgres psql dsmrreader

# Voer deze query uit.
SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
  FROM pg_class C
  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema')
    AND C.relkind <> 'i'
    AND nspname !~ '^pg_toast'
  ORDER BY pg_total_relation_size(C.oid) DESC
  LIMIT 20;

# Bewaar het resultaat

# Druk een paar keer op CTRL + D om weer uit de database te gaan.

Je kunt evt hier delen wat je bevindingen zijn in de verschillen.

[newtech2015]

hallo dennis, even de tijd genomen, om alles mbt data verlies door slechte sd kaart en backuppen eens te laten bezinken.Lijkt me een goed plan, om de database op een iets anders op te slaan, dan een sd-kaart... bv een externe hdd. ik zag overigens al een beschrijving over het veranderen van database locatie, naar bv een usb stick.. maar, is een usb stick dan beter bestand tegen veelvuldig schrijven en lezen, of is dat intern t zelfde als een sd kaarte? maar, gezien er in dsmr al gebruik wordt gemaakt van dropbox.. kan dat niet daarop, of is dat erg lastig? gr ron

[dennissiemensma]

Het is helaas niet sluitend te krijgen, zonder dat je er iets anders op aansluit, zoals een externe HDD. Of het hosten op een server/NAS.