Sauvegarde et restauration

L'application s'appelle « Ticket System Backup & Restore ». Elle se trouve à côté du système de tickets et a son propre raccourci sur le bureau.

Il y a une version pour Windows et une pour Linux. C'est la même application, simplement construite pour chaque système d'exploitation.

Elle a six onglets. « Restore » liste les sauvegardes dont tu disposes, « Create Backup » en fait une nouvelle, « Schedule » gère l'horaire, « Encryption » montre la clé de récupération, « Settings » montre les chemins et « Log » le journal.

Les paramètres sont déjà remplis. À son premier démarrage, l'application détermine elle-même où se trouve le système de tickets.

Le dossier des sauvegardes se trouve sous « Backup directory ». Tu peux le changer, par exemple pour un autre disque.

Sous Windows, l'application demande des droits d'administrateur au démarrage. Ses réglages valent pour tous les administrateurs de l'ordinateur et se trouvent dans « %ProgramData%\SMITEY\backup-app ».

L'installation met en place la sauvegarde quotidienne toute seule. Elle tourne à 23 h dans le fuseau horaire du système de tickets.

L'horaire vit dans le système d'exploitation. Sous Windows, c'est le planificateur de tâches, sous Linux le service cron. Aucun service supplémentaire ne tourne donc juste pour les sauvegardes.

La sauvegarde n'a besoin de personne de connecté. Sur un serveur où personne ne se connecte jamais, elle tourne quand même.

La ligne sous les boutons te dit si la tâche existe vraiment dans le système d'exploitation. Une case cochée ne dit que ce qui a été enregistré.

Les sauvegardes sont conservées sur cinq niveaux : 14 jours, 4 semaines, 12 mois, 4 trimestres et 5 années. Une sauvegarde reste tant qu'elle est la plus récente de sa période dans l'un de ces niveaux.

Ce qui compte, ce sont les jours du calendrier, pas les fichiers. Deux sauvegardes le même jour font un jour.

Les sauvegardes que tu crées à la main ne sont jamais supprimées automatiquement. C'est ce que veut dire le 0 à « Keep manual ».

Si tu changes l'horaire, ton changement survit à une mise à jour. L'installation ne le pose que si tu n'as jamais posé d'horaire. Si tu as désactivé la sauvegarde, elle reste désactivée. « Remove all scheduled tasks » tient aussi : une mise à jour ne remet pas l'horaire en place ensuite.

Une sauvegarde contient tout ce qui compose l'état de ton système. C'est-à-dire la base de données, les pièces jointes, l'archive et les clés. Seule une base de données en dehors de SMITEY n'en fait pas partie.

Les clés sont la partie qu'on oublie facilement. Elles déchiffrent les identifiants enregistrés, par exemple ceux de ton compte de messagerie. Sans elles, une restauration reviendrait avec des identifiants morts.

Chaque nouvelle sauvegarde est un seul fichier chiffré se terminant par « .smbk ». Il contient un fichier par volume, une liste de son contenu et la base de données sous forme de fichier texte, si elle est incluse.

Le système continue de tourner pendant ce temps. Tes agents ne remarquent pas du tout une sauvegarde.

« Estimate size » t'indique à l'avance la taille de la base de données. Les volumes avec les pièces jointes s'y ajoutent. La sauvegarde n'est pas compressée.

Rien n'est jamais écrasé. Chaque sauvegarde est un fichier à part, et seul le nettoyage supprime les anciennes.

Seuls les administrateurs peuvent lire les sauvegardes. Il en va de même pour le fichier de configuration et pour le fichier avec la première connexion dans le dossier d'installation. Le programme d'installation et chaque mise à jour définissent eux-mêmes ces droits.

Si ta base de données tourne sur son propre serveur et non dans le conteneur SMITEY, l'application ne peut pas la sauvegarder. Sauvegarde-la alors avec tes propres outils. Dans ce cas, la sauvegarde ne contient que les pièces jointes, les archives et les clés, chiffrées comme d'habitude. Une mise à jour détecte elle-même une telle base de données et change le réglage de l'application. Jusque-là, la sauvegarde quotidienne échoue sur une telle installation, sauf si tu changes d'abord le réglage à la main. Sur la ligne de commande, tu peux aussi le faire à la main avec « config --database external ». Avec « config --database bundled », tu reviens au réglage précédent.

Chaque nouvelle sauvegarde est chiffrée. Cela vaut pour les sauvegardes de l'horaire, celles faites à la main et celles avant une mise à jour. Tu n'as rien à activer.

Les sauvegardes sont chiffrées avec AES-256. L'installation crée la clé elle-même. Sur une installation existante, elle est créée lors de la première mise à jour vers une version avec chiffrement. Elle est stockée protégée sur le serveur. Seuls les administrateurs peuvent la lire.

Cela protège les copies en dehors du serveur. Celui qui trouve une sauvegarde sur un lecteur réseau, une clé USB ou un stockage en ligne ne peut pas la lire sans la clé. Celui qui contrôle le serveur lui-même a aussi la clé.

La clé de récupération est la même clé sous une forme que tu peux noter. Elle commence par « SMBK- ». Tu la trouves dans l'onglet « Encryption » et dans le fichier « SMITEY-credentials.txt » du dossier d'installation. Si tu as supprimé ce fichier, tu trouves quand même la clé dans l'onglet « Encryption ».

« Copy » place la clé dans le presse-papiers. « Save to file... » l'enregistre avec l'ID de clé et la date dans un fichier texte. Conserve-le par exemple dans un gestionnaire de mots de passe ou sur papier dans un coffre.

Tant que tu n'as pas confirmé que la clé est conservée, l'application affiche une barre jaune en haut. Pour confirmer, clique sur « I stored the key outside this server » et réponds à la question par « Yes ». La barre disparaît alors. L'onglet indique ensuite quand tu as confirmé.

L'ID de clé t'indique à quel serveur appartient une sauvegarde. Si une sauvegarde n'appartient pas à ce serveur, l'application nomme son ID de clé. Elle demande ensuite la clé de récupération correspondante.

Si l'application ne peut pas lire la clé, elle ne fait pas de sauvegarde. Elle n'en fait pas non plus de non chiffrée. Dans ce cas, l'onglet « Encryption » indique que la clé ne peut pas être lue. Si le fichier de clé manque complètement, la sauvegarde suivante crée une nouvelle clé. La barre jaune réapparaît alors, car la nouvelle clé doit aussi être conservée. Les anciennes sauvegardes ne peuvent toujours être ouvertes qu'avec l'ancienne clé de récupération.

Les anciennes sauvegardes au format ZIP ne sont pas chiffrées. Tu peux encore les restaurer. L'onglet indique combien il y en a. Le nettoyage les supprime selon les mêmes règles que n'importe quelle autre sauvegarde.

Sur un serveur sans bureau, « key --show » affiche la même chose sur la ligne de commande.

Dans l'onglet « Restore », tu choisis la sauvegarde que tu veux récupérer. Puis tu cliques sur « Restore ».

L'application demande d'abord. Elle dit ce qui va se passer : l'état du jour est écrasé, et l'application redémarre les conteneurs. Si des personnes sont anonymisées dans l'état du jour, une deuxième question suit. Elle indique leur nombre et demande s'il faut les anonymiser à nouveau après la restauration. « Yes » est présélectionné. Avec « No », la sauvegarde est restaurée sans cette étape. Si tu fermes la fenêtre à la place, rien n'est restauré.

La case « Wipe target volumes before restore » vide d'abord les volumes. Ainsi, aucun fichier ne subsiste qui n'existait pas au moment de la sauvegarde.

Les étapes apparaissent dans l'onglet « Log ». Tu y vois une par une ce que l'application a fait. Si tu as répondu « Yes » à la deuxième question, une ligne à la fin indique combien d'anonymisations le système de tickets applique de nouveau la nuit suivante. Si elles ne peuvent pas être reprises, le journal affiche à la place un avertissement. S'il y a eu des avertissements, la ligne d'état en bas de la fenêtre indique leur nombre.

Si la sauvegarde contient la base de données, l'état complet revient. Les tickets, les commentaires, l'historique, les pièces jointes, le temps saisi et la base de connaissances sont tous de nouveau là tels qu'ils étaient au moment de la sauvegarde.

Ensuite, le système est de nouveau utilisable. Sur une petite installation, cela prend moins d'une minute.

Si la sauvegarde contient la base de données, celle-ci revient entièrement ou pas du tout. Les volumes suivent ensuite. Si un volume échoue, la base de données est déjà revenue, mais des fichiers peuvent manquer ; l'onglet « Log » montre quelle étape a échoué. Dans tous les cas, l'application redémarre ensuite les conteneurs, même si la restauration a échoué.

Une sauvegarde d'une version plus ancienne peut être restaurée dans une version plus récente. À son prochain démarrage, le système met la base de données au niveau de sa propre version.

Les consentements et désabonnements pour l'enquête de satisfaction sont repris sans question. Cela vaut aussi si tu réponds « No » à la deuxième question. L'application les lit dans l'installation en cours avant la restauration. Ensuite, une ligne dans l'onglet « Log » indique le nombre, par exemple « 12 consent and unsubscribe record(s) were carried over. » Le système de tickets les reprend à son premier démarrage. Un consentement ou un désabonnement fait après la sauvegarde reste donc valable. Si le transfert échoue, le journal affiche un avertissement. La restauration compte quand même comme réussie.

L'application vérifie d'abord entièrement une sauvegarde chiffrée. Pendant ce temps, la ligne d'état indique « Checking the encrypted backup before anything is changed... ». Ce n'est qu'ensuite qu'elle arrête les conteneurs. Si le fichier est endommagé ou a été modifié, elle s'arrête et signale « The backup file is damaged. Nothing was changed. »

Si la sauvegarde vient d'un autre serveur, l'application demande la clé de récupération de ce serveur. Cela se passe après les questions. La fenêtre « Recovery key needed » nomme l'ID de clé de la sauvegarde. La même fenêtre apparaît si la clé de ce serveur manque.

Une faute de frappe est repérée avant que quoi que ce soit ne change. La ligne d'état signale alors « The recovery key has a typing error. Check each character. » Ensuite, la fenêtre redemande. Si la clé appartient à une autre sauvegarde, la ligne d'état signale « This recovery key does not belong to this backup. » Avec « Cancel », l'application s'arrête et signale « Restore cancelled. Nothing was changed. »

L'application n'adopte pas la clé que tu as saisie. Elle garde la sienne. Les nouvelles sauvegardes sont toujours faites avec la clé de ce serveur. Si tu restaures sur un nouveau serveur, conserve aussi la clé de récupération de ce serveur.

Une sauvegarde sans base de données ne restaure que les pièces jointes, les archives et les clés. Les clés existantes sont conservées. La base de données reste telle quelle. L'application le dit avant la restauration et demande. Avec « No », rien n'est modifié.

Si l'installation est configurée avec sa propre base de données, l'application ignore la partie base de données même quand la sauvegarde contient une base de données. C'est le cas par exemple d'une sauvegarde plus ancienne. L'application demande d'abord. Avec « No », rien n'est modifié.

Un serveur n'a souvent pas de bureau. La même application fonctionne donc aussi comme commande.

Cinq commandes suffisent au quotidien : « backup » sauvegarde, « list » montre les sauvegardes dont tu disposes, « restore » en ramène une, « schedule » règle l'horaire et « config » montre les paramètres. Pour la clé, « key » et « decrypt » s'y ajoutent.

Derrière elles se trouve la même application que dans la fenêtre. Il n'y a pas de seconde voie qui ferait autre chose.

L'application se trouve dans « /opt/smitey/Backup ». Tu l'appelles avec « sudo » et tu ajoutes la commande. Les conteneurs tournent en « root », la sauvegarde a donc besoin de ces droits aussi.

Tu peux copier les six encadrés ci-dessous. Ils couvrent ce qui sert vraiment au quotidien.

Une restauration demande confirmation ici aussi. Elle ne s'exécute que si tu ajoutes « --yes ». Elle reprend alors aussi les anonymisations de l'état du jour, comme « Yes » dans la fenêtre. Avec « --no-reapply », elle s'exécute sans cette étape.

Il y a un fichier sur le serveur pour approfondir tout cela. Il s'appelle « BACKUP-RESTORE.txt » et se trouve dans « /opt/smitey ». Il reprend l'horaire, chaque commande et le chemin du retour, à ton rythme. Il existe en allemand et en anglais : si tu as choisi l'allemand pendant l'installation, tu reçois la version allemande, sinon la version anglaise. Les deux versions se trouvent aussi sous « /opt/smitey/docs ».

« key --show » affiche la clé de récupération, l'ID de clé et le nombre de sauvegardes non chiffrées. Une fois la clé conservée en dehors du serveur, tu le confirmes avec « key --confirm-stored ».

Tu restaures une sauvegarde d'un autre serveur avec « --key-file ». Le fichier que tu indiques contient la clé de récupération. Le fichier de « Save to file... » convient aussi. À la place du fichier, tu peux aussi utiliser la variable d'environnement « SMITEY_BACKUP_KEY ». Avec « sudo », tu la places directement devant le programme, c'est-à-dire « sudo SMITEY_BACKUP_KEY=<clé> /opt/smitey/Backup/TicketSystemBackup restore … ». La clé se retrouve alors dans l'historique du shell. Si la clé ne correspond pas, rien n'est modifié.

« decrypt » écrit le contenu d'une sauvegarde sous forme de fichiers non chiffrés dans un dossier vide. Ces fichiers ne sont pas chiffrés. Ils contiennent des mots de passe et des données personnelles. Supprime-les dès que tu as terminé.

Les sauvegardes sont des fichiers dans le dossier que tu as réglé. Ce dossier est sur la même machine que le système de tickets.

Pour les cas courants, cela fonctionne bien. Des données supprimées par erreur, une mise à jour qui a mal tourné ou une erreur dans les données sont toutes couvertes.

Cela n'aide pas contre la panne du disque. Si le disque est perdu, les sauvegardes le sont avec lui.

Copie donc les fichiers ailleurs. Un lecteur réseau, un second serveur ou un stockage sur le réseau suffisent.

Un fichier copié peut être rechargé sur n'importe quel serveur. Sur un autre serveur, tu as besoin pour cela de la clé de récupération. Avec « Import backup file… », tu ramènes le fichier dans la liste.

Les copies sont chiffrées. Personne ne peut les lire sans la clé de récupération. Ne conserve donc pas la clé à côté des copies. Les anciennes sauvegardes se terminant par « .zip » ne sont pas chiffrées.

Une mise à jour fait sa propre sauvegarde au préalable. Cela se produit indépendamment de ton horaire et sans que tu coches quoi que ce soit.

Elle sauvegarde la même chose que d'habitude : la base de données, les pièces jointes, les archives et les clés. Si la base de données tourne en dehors de SMITEY, la mise à jour ne sauvegarde que les pièces jointes, les archives et les clés.

Cette sauvegarde est faite par l'application « Ticket System Backup & Restore ». Elle est chiffrée comme toutes les autres et se trouve dans le même dossier. Dans la liste, son type est « Update ». Les trois plus récentes de ces sauvegardes sont conservées. L'application supprime les plus anciennes elle-même.

L'avis affiché avant la mise à jour te le dit. Tu n'as pas à penser à sauvegarder toi-même d'abord.

Si cette sauvegarde échoue, la mise à jour s'arrête avant que quoi que ce soit ne soit remplacé. Une base de données en dehors de SMITEY ne retarde pas la mise à jour. La mise à jour change alors le réglage de l'application pour que la sauvegarde quotidienne laisse aussi la base de données de côté. Sauvegarde cette base de données avec tes propres outils.