Le versioning S3 n'est pas une sauvegarde
Versioning, réplication, verrouillage d'objets : trois mécanismes utiles, tous logés dans le compte qu'ils sont censés protéger. Voici où ils s'arrêtent, et ce qu'il faut mettre derrière.
Le versioning S3 conserve les versions successives d'un objet. Quand une écriture écrase un fichier, l'ancienne version reste accessible et la restauration est immédiate. Contre l'erreur d'un utilisateur ou d'un script sur un objet, c'est efficace, et il faut l'activer.
Son périmètre s'arrête à l'objet. Le versioning ne recrée pas un bucket supprimé, ne survit pas à la fermeture du compte, et ne résiste pas à quelqu'un qui détient vos identifiants : les versions se suppriment avec les mêmes clés que les objets, souvent en une seule commande de purge. Le mécanisme vit dans le compte qu'il est censé protéger, ce qui le rend inopérant précisément dans les scénarios les plus graves.
La réplication propage l'incident
La réplication inter-région ou inter-bucket copie automatiquement chaque écriture vers une destination. Elle répond à un besoin de disponibilité : si une région tombe, la donnée est ailleurs. C'est une réponse à la panne, pas à l'erreur.
Sa logique est fidèle par construction. Un objet chiffré par un rançongiciel est répliqué chiffré. Une suppression est répliquée en suppression. Le délai entre l'incident et sa propagation se compte en secondes, bien avant que quiconque ait vu passer une alerte. À la fin, vous avez deux copies du même désastre.
Une sauvegarde fonctionne à l'inverse : elle conserve des états antérieurs figés, indépendants de ce qui arrive ensuite à la source. C'est la seule propriété qui permette de revenir en arrière.
Ce que les mécanismes natifs ne couvrent pas
- La suppression du bucket lui-même, versions comprises
- Une clé d'accès qui fuite et permet de purger objets et versions
- La compromission du compte, qui donne la main sur la source et sur ses réplicas
- La fermeture du compte, volontaire, contractuelle ou pour impayé
- Une politique de cycle de vie mal écrite qui expire les anciennes versions
Et le verrouillage d'objets ?
Le verrouillage d'objets, ou object lock, empêche la suppression d'une version pendant une durée définie. C'est le plus solide des trois mécanismes, et il mérite d'être activé sur les données critiques.
Il reste soumis à la même limite : il dépend du compte et du fournisseur qui l'appliquent. Il ne protège pas d'une fermeture de compte, d'un litige commercial ou d'une indisponibilité prolongée du fournisseur. Et il complique le respect du droit à l'effacement du RGPD, puisqu'il interdit par construction de supprimer avant terme.
Ce qu'il faut derrière
La règle est ancienne et elle tient toujours : une copie doit exister hors du périmètre qu'elle protège. Pour un bucket, cela signifie hors du compte, et de préférence hors du fournisseur. Sinon, un seul incident d'authentification emporte tout.
Kryolys sauvegarde vos buckets S3 et compatibles vers une infrastructure française indépendante. Vous déclarez le bucket dans la console, la sauvegarde tourne seule, les snapshots sont datés et chiffrés avec la clé de votre organisation. La restauration vise le bucket d'origine ou un autre bucket. Voir la sauvegarde de bucket S3.
Questions fréquentes
Faut-il désactiver le versioning si on a une sauvegarde ?
Non, les deux se complètent. Le versioning règle en quelques secondes les erreurs courantes sur un objet, sans quitter le fournisseur. La sauvegarde couvre ce qu'il ne voit pas : perte du bucket, du compte ou des identifiants. Gardez les deux.
Le stockage objet n'est-il pas déjà durable à onze neuf ?
Cette durabilité porte sur la perte de données par défaillance matérielle. Elle ne dit rien des suppressions, qui sont des opérations légitimes du point de vue du service. Le fournisseur exécute et réplique un DELETE valide, c'est son travail.
Une copie vers un second bucket du même compte suffit-elle ?
Non. Les deux buckets partagent le compte, la facturation et souvent les mêmes identifiants. Une clé compromise ou un compte fermé emporte les deux. La copie doit sortir du compte pour avoir une valeur.
Quel est le tarif de la sauvegarde de stockage objet chez Kryolys ?
7,50 € HT par To sauvegardé et par mois, dès le plus petit bucket, avec un premier To dû par organisation puis une facturation au Go au-delà. Les comptes SaaS sont à 3 € HT par compte et par mois, les machines à 9 € HT par To sauvegardé et par mois. 365 jours d'historique inclus dans les trois cas.
Un compte Microsoft 365, Google Workspace ou IMAP. Facturé au siège, quel que soit le volume sauvegardé.
- Mails, fichiers, agendas et contacts
- Snapshots datés, restauration ciblée
- 365 jours d'historique inclus
Une VM, un serveur ou un poste, agent léger inclus. Facturé au volume.
- Facturation au Go au-delà du premier To
- Restauration jusqu'à la machine entière
- 365 jours d'historique inclus
Un bucket S3 ou compatible, chez votre fournisseur ou chez vous. Facturé au volume, dès le plus petit bucket.
- Facturation au Go au-delà du premier To
- Restauration vers le bucket d'origine ou un autre
- 365 jours d'historique inclus
Une copie dans le même compte n'est pas une copie.
Rejoignez la beta.
Kryolys ouvre progressivement. Laissez votre adresse, nous vous prévenons dès que votre accès est prêt, avec une période d'essai gratuite.
L'inscription demande JavaScript. Vous pouvez aussi nous écrire à support@kryolys.com, nous vous ajouterons à la liste.
C'est noté. Vérifiez votre boîte mail pour confirmer votre inscription.
Une erreur est survenue. Réessayez dans un instant, ou écrivez-nous directement.