On devrait toujours regarder de prêt les logs systèmes : dans mon cas, les problèmes ont commencé par de sporadiques erreurs avec le disque dur. En particulier des

Feb 27 03:29:43 bPI smartd[1884]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 10 Spin_Retry_Count changed from 105 to 106

Ce message indique que le disque, pour une raison indéterminée, avait perdu sa vitesse de rotation nominale. Hum, disque en train de lâcher où autre problème.
Au début, j'étais parti sur la première possibilité surtout que dit disque avait planté à plusieurs reprises pendant de gros transfères.

On suivi des

Feb 27 03:27:50 bPI kernel: [3825266.421044] ata1: hard resetting link
Feb 27 03:27:53 bPI kernel: [3825268.731328] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Feb 27 03:27:53 bPI kernel: [3825268.771908] ata1.00: configured for UDMA/33
Feb 27 03:27:53 bPI kernel: [3825268.801748] ata1: EH complete

qui indiquent ce coup-ci que le lien avec le disque a été très ponctuellement perdu. Aïe aïe aïe.

Mais quand arrivent des

Mar  2 13:31:13 bPI usbhid-ups[2237]: libusb_get_interrupt: No such device or address
Mar  2 13:31:15 bPI upsd[1940]: Data for UPS [onduleur] is stale - check driver

le problème vient forcément d'ailleurs : en fait, c'est l'alim à 2 balles qui est en train de lâcher .

Evidemment, tout ceci est arrivé pendant nos vacances laissant bien le temps de faire des dégâts.

Heureusement, le bPI et ses périphs ont bien résisté à toute cette maltraitance et si le disque lui-même ne semble pas avoir souffert, ses arrêts intempestifs ont créé des corruptions sur les données en cours de mise à jour.

Pour les filesystems, un simple fschk a suffi à réparer ce qui devait l'être. Malheureusement, ça a été une autre histoire avec la base de données.

Avant toute tentative de correction, une bonne sauvegarde s'impose : heu ...

$ pg_dumpall --clean > /tmp/db.sql
pg_dump: [archiver (db)] query failed: ERROR:  MultiXactId 114439 has not been created yet -- apparent wraparound
pg_dump: [archiver (db)] query was: SELECT c.tableoid, c.oid, c.relname, c.relacl, c.relkind, c.relnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = c.relowner) AS rolname, c.relchecks, c.relhastriggers, c.relhasindex, c.relhasrules, c.relhasoids, c.relrowsecurity, c.relforcerowsecurity, c.relfrozenxid, c.relminmxid, tc.oid AS toid, tc.relfrozenxid AS tfrozenxid, tc.relminmxid AS tminmxid, c.relpersistence, c.relispopulated, c.relreplident, c.relpages, CASE WHEN c.reloftype <> 0 THEN c.reloftype::pg_catalog.regtype ELSE NULL END AS reloftype, d.refobjid AS owning_tab, d.refobjsubid AS owning_col, (SELECT spcname FROM pg_tablespace t WHERE t.oid = c.reltablespace) AS reltablespace, array_remove(array_remove(c.reloptions,'check_option=local'),'check_option=cascaded') AS reloptions, CASE WHEN 'check_option=local' = ANY (c.reloptions) THEN 'LOCAL'::text WHEN 'check_option=cascaded' = ANY (c.reloptions) THEN 'CASCADED'::text ELSE NULL END AS checkoption, tc.reloptions AS toast_reloptions FROM pg_class c LEFT JOIN pg_depend d ON (c.relkind = 'S' AND d.classid = c.tableoid AND d.objid = c.oid AND d.objsubid = 0 AND d.refclassid = c.tableoid AND d.deptype = 'a') LEFT JOIN pg_class tc ON (c.reltoastrelid = tc.oid) WHERE c.relkind in ('r', 'S', 'v', 'c', 'm', 'f') ORDER BY c.oid
pg_dumpall: pg_dump failed on database "www", exiting

Signe d'une corruption critique de la BDD. Malheureusement, tout ce que j'ai trouvé sur le web à ce propos n'ont pas fonctionné : voici donc comment je m'y suis pris pour récupérer la situation.

Les selects sur les tables importantes fonctionnant, il semblerait que seules les méta données ont giclé ... mes données sont toujours accessibles mais malheureusement je ne peux pas utiliser les outils de postgres. La seule solution est donc de jouer le backup ... mais comme il date de plus d'1 mois, il va falloir essayer de sauvegarder les données fraiches importantes.
En effet, ma base est utilisée pour stocker les informations de toute ma domotique et des paramètres de mes machines. Si la perte de certaines d'entres elles n'a aucune importance (typiquement les charges CPU ...), d'autres méritent des efforts pour être conservé comme la production électrique.

Nous avons déterminé quelles sont les données importantes ... et par conséquence les tables importantes. Dans mon cas, ça sera

• Les compteurs électriques : probe_counter  probe_counter_archive  probe_counter_statistics
• Les températures et autres archivages de la domotique : probe_hardware  probe_hardware_archive

que nous sauvegarderons avec la commande suivante

www=# copy domestik.probe_hardware_archive to '/tmp/r/probe_hardware_archive';

Sous Gentoo, les datafiles de la base se trouve dans le répertoire <version_postgres> du home de l'utilisateur postgres. Bref, avec ma base 9.5, ce répertoire sera ~postgres/9.5

• On stoppe la BDD

# /etc/init.d/apache2 stop

• On garde une copie de l'ancienne BDD

# /etc/init.d/postgresql-9.5 stop

• On crée le nouveau cluster

# emerge --config dev-db/postgresql:9.5

• On redémarre la BDD

# /etc/init.d/postgresql-9.5 start

Sous postgres, on charge le backup

$ psql template1 < /tmp/db.sql

Malheureusement, ses données ont donc 50 jours, il faut charger les tables précédement sauvegardées.

www=# truncate domestik.probe_counter;
TRUNCATE TABLE
www=# copy domestik.probe_counter from '/tmp/r/probe_counter';
COPY 501

Et voila, plus de peur que de mal pour ce coup-ci ... va falloir que j'améliore

• mes sauvegardes car 50j, c'est quand même beaucoup trop.
• mon monitoring pour que ce genre de pb remonte avant que ce ne soit la cata.