Restaurer

Restaurer un backup remplace votre base de données et vos fichiers media actuels par le contenu d'une archive de backup. Restaurez depuis un fichier téléversé, depuis un backup stocké sur ce serveur, depuis une copie DO Spaces distante, ou via l'API.

Ce qui est remplacé

Un restore remplace :

la base de données
le répertoire media
les fichiers de thème et les templates de site, quand le backup les contient
les métadonnées de thème, quand elles sont incluses

L'action ne peut pas être annulée, donc l'interface vous avertit avant tout changement et vous demande de confirmer.

D'où vous restaurez

Téléversez un fichier de backup depuis le formulaire Restore from Backup sur l'écran Backups. Le fichier doit être une archive .tar.gz de 50 Mio maximum.

Restaurez un backup local depuis la liste des archives conservées sur le serveur, avec son bouton Preview ou Restore. Les fichiers de backup locaux sont reconnus à leur motif de nommage chinaski_backup_<timestamp>.tar.gz.

Restaurez depuis DO Spaces: si Spaces est configuré sous Settings → Integrations, vous pouvez restaurer depuis une liste de backups distants. Sur une instance air-gapped, le restore distant est désactivé.

Restore par API: un endpoint permet aux clients munis d'une clé API write de restaurer un backup local nommé, avec le même preview de dry-run qu'utilisent les écrans admin.

Prévisualisez toujours d'abord

Cliquez sur Preview (dry run) avant de restaurer. Un dry run lit l'archive et rapporte, sans rien changer :

le type, la date de création, le hostname et la version du CMS du backup
sa version de schéma comparée à la vôtre : un écart est mis en évidence et garantit que le restore avortera
ce que l'archive contient (media, thèmes, templates de site)
le résultat d'un contrôle d'intégrité sur la base de données sauvegardée
les éventuels échecs de validation ou avertissements de backup legacy

Les backups créés par une version récente incluent un manifest de checksum. S'il est présent, le restore vérifie chaque fichier de l'archive contre son checksum SHA-256 enregistré ; les écarts avortent le restore avec « backup may be corrupted or tampered with ». Les anciens backups « legacy » se restaurent normalement mais vous informent que les checksums n'ont pas été vérifiés.

Pour les backups téléversés, la vérification porte sur le fichier staged exact que vous avez prévisualisé, de sorte que ce que vous confirmez est ce qui est appliqué. Si de nouveaux previews remplacent ce téléversement staged, la confirmation antérieure est refusée.

Ce qui est imposé

Ces portes s'exécutent avant tout changement :

La version de schéma doit correspondre exactement. Un backup d'une autre version de schéma avorte entièrement le restore avant tout changement.
L'archive doit contenir le fichier de base de données: tout ce qui n'est pas un backup Chinaski est refusé.
Les fichiers doivent rester dans l'archive. L'extraction parcourt la liste des emplacements et avorte si une entrée tente de s'échapper du répertoire d'extraction (astuces de symlink ou de path traversal).
Les checksums doivent correspondre. Quand l'archive porte un manifest, chaque fichier listé est vérifié en SHA-256.
Un timeout de 120 secondes s'applique aux téléchargements et à l'extraction ; un restore qui ne finit pas à temps est écarté plutôt qu'appliqué en retard.

Ce qui est affiché en cas de succès, et ce que vous devez faire

Une fois qu'un restore commence à s'appliquer, la base de données est remplacée d'abord, atomiquement. Puis le media, les thèmes et les templates de site suivent :

Sur un restore propre vous voyez « Backup restored : database, media, and themes have been replaced ». Les restores distants/API vous disent la même chose et ajoutent : redémarrez le service pour recharger la base de données. Redémarrer après tout restore est une pratique sensée.
Si seule la base de données est restaurée mais que le media n'a pas pu être échangé (rare, généralement des permissions), le message vous dit de relancer le restore pour retenter l'étape media.
Si la restauration des thèmes ou des templates de site a échoué alors que tout le reste a fonctionné, le flash nomme ce qu'il faut vérifier.
Les restores réussis sont consignés dans le journal d'audit avec l'origine du backup.