Suppression accidentelle d'un champ personalisé dans wekan

Bonjour,
Croyant supprimer une valeur dans un menu personalisé, j’ai cliqué sur Supprimer ce qui a supprimé le menu personalisé et non pas la valeur. Il ne semble pas être possible d’annuler ce changement, comment faut-il faire pour retrouver les informations perdues ?

Il suffit de restaurer la sauvegarde qui a été faite dans la nuit. Cela veut dire perdre les modifications faites ce matin. Ca tombe bien, on a fait un exercice de ce genre il y a peu et ça donne l’occasion de mettre en pratique :slight_smile:

Il y a une difficulté supplémentaire, mais cela ne devrait pas poser de problèmes: la machine sur laquelle tourne wekan a été partagée (pour réduire les coûts de fonctionnement) avec d’autres services. On ne peut donc pas utiliser la méthode de restauration la plus simple qui consiste à ressusciter la machine telle qu’elle était la nuit dernière. Parce que cela voudrait dire perdre les modifications faites ce matin sur les autres services, ce qui serait dommage. Au lieu de ça on va:

  • Resusciter le service tel qu’il était cette nuit mais dans un environnement de test
  • Faire une sauvegarde de wekan dans l’environnement de test
  • Copier la sauvegarde de wekan depuis l’environnement de test vers l’environnement de production
  • Demander à wekan de restaurer la sauvegarde
1 Like

The machine does not have much RAM and when running

$ /snap/bin/wekan.database-restore /var/snap/wekan/common/db-backups/wekan-20201001T210419.backup

it crashed. After a reboot, the other services were stopped temporarily and only wekan remained. But the restore failed with:

$ /snap/bin/wekan.database-restore /var/snap/wekan/common/db-backups/wekan-20201001T210419.backup
...
2020-10-01T22:08:12.681+0000    restoring wekan.users from archive '/var/snap/wekan/common/db-backups/wekan-20201001T210419.backup'           
2020-10-01T22:08:12.789+0000    error: multiple errors in bulk operation:                                                                                        
  - E11000 duplicate key error collection: wekan.unsaved-edits index: _id_ dup key: { : "9Aa3Dp72utEk6aeHQ" }                                                            
  - E11000 duplicate key error collection: wekan.unsaved-edits index: _id_ dup key: { : "4TkynMnXs9dRa24L6" }                                                           
  - E11000 duplicate key error collection: wekan.unsaved-edits index: _id_ dup key: { : "q27yPySJq7WuYB5Mn" }                                                

Although wekan was up, the data was inconsistent: something was broken. Since wekan was the only snap based package installed, I rsynced all of /srv/snap and /srv/snapd from the backup volume instead of relying on the wekan backup and restore mechanism. Running as root:

$ snap stop wekan
$ systemctl stop snapd
$ RSYNC_RSH='ssh -i /tmp/infrastructure_key' rsync --delete -avH --numeric-ids root@website-host.recover01.d.enough.community:/srv/snap/ /srv/snap/
$ RSYNC_RSH='ssh -i /tmp/infrastructure_key' rsync --delete -avH --numeric-ids root@website-host.recover01.d.enough.community:/srv/snapd/ /srv/snapd/
$ systemctl start snapd
$ snap start wekan

Note that it is very difficult to shutdown snap completely because it has many services installed that rely on systemd to mount volumes and create loop volumes.

$ systemctl list-units
run-snapd-ns-wekan.mnt.mount  loaded active mounted   /run/snapd/ns/wekan.mnt
run-snapd-ns.mount            loaded active mounted   /run/snapd/ns
snap-core-9804.mount          loaded active mounted   Mount unit for core, revision 9804
snap-core-9993.mount          loaded active mounted   Mount unit for core, revision 9993
snap-wekan-1020.mount         loaded active mounted   Mount unit for wekan, revision 1020
snap-wekan-1021.mount         loaded active mounted   Mount unit for wekan, revision 1021
var-lib-snapd.mount           loaded active mounted   /var/lib/snapd
var-snap.mount                loaded active mounted   /var/snap
snap.wekan.mongodb.service    loaded active running   Service for snap application wekan.mongodb
snap.wekan.wekan.service      loaded active running   Service for snap application wekan.wekan
snapd.service                 loaded active running   Snappy daemon
snapd.socket                  loaded active running   Socket activation for snappy daemon
$ mount | grep snap
/var/lib/snapd/snaps/core_9993.snap on /snap/core/9993 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/wekan_1021.snap on /snap/wekan/1021 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/wekan_1020.snap on /snap/wekan/1020 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_9804.snap on /snap/core/9804 type squashfs (ro,nodev,relatime,x-gdu.hide)

If a backup was to be restored with a version of wekan or core that does not match, the rsync may create chaos instead of fixing things.

The ultimate solution, if everything goes sideways trying to restore one service without restoring the others is to restore the entire machine, therefore loosing one day’s worth of work on the other services as well.

J’ai fait une erreur en communiquant à propos de cette restauration de sauvegarde. J’ai dit que les modifications du tableau wekan contenant le champ personnalisé seraient perdues. Alors que j’aurais du dire:

  • toutes les modifications faites dans wekan entre 4am et 11:30am vont être perdues

et au lieu de laisser wekan tourner j’aurais du l’arrêter pour éviter que de nouvelles modifications soient faites avant que la sauvegarde soit restaurée. Plusieurs utilisateurs ont perdu leur travail de la journée à cause de cela.