Sauvegardes et chiffrement

Une sauvegarde n'a de valeur que le jour où l'on s'en sert. Voici ce qui distingue une sauvegarde sur laquelle on peut compter d'une copie qui rassure seulement.

Une sauvegarde qu'on a déjà restaurée

Beaucoup de sauvegardes échouent sans bruit : un fichier tronqué, une collection oubliée, une clé de chiffrement perdue. La seule preuve qu'une sauvegarde est bonne est de la restaurer. IshedDB relit chaque sauvegarde en entier juste après l'avoir faite, et vérifie qu'elle se restaure, documents, définitions et vues compris.

Chiffrée, et loin du serveur

• Chiffrée (AES-256) avant de quitter le serveur : une copie volée est illisible sans la clé, gardée à part.
• Copiée hors du serveur : un incendie, une panne de disque ou une erreur sur le serveur ne l'emportent pas.
• Verrouillée : la copie ne peut être ni effacée ni modifiée pendant 30 jours, par personne, nous compris. Un logiciel de rançon qui prendrait la main sur le serveur ne pourrait pas la détruire.

Revenir à un instant précis

Une sauvegarde de la nuit ramène les données de la nuit ; ce qui a été écrit depuis est perdu. Pour une erreur de manipulation à 15 h, il faut mieux : revenir à 14 h 59.

Sur le palier Dédié, IshedDB garde un journal de chaque changement pendant 1 à 7 jours. Restaurer à un instant, c'est défaire, du plus récent au plus ancien, tout ce qui a été écrit après lui, en une seule fois. Et une restauration se défait elle-même, si l'on s'est trompé d'instant.

Le chiffrement en transit

Entre votre application et la base, tout passe en HTTPS : une requête en clair est refusée, et les bibliothèques d'IshedDB refusent d'envoyer une clé ailleurs.

Garder une copie chez soi

Pour une exigence de votre organisation, ou pour déplacer des données, le shell ished fait aussi des sauvegardes complètes chez vous (ished dump), définitions comprises, et les remet (ished restore).

Pour aller plus loin

• Le Centre de confiance.
• Les produits : la sauvegarde dans la plateforme.