Résumé

  • Le choix du dépôt de sauvegarde et la possibilité de lancer une restauration ne prouvent pas, seuls, qu’une application pourra redémarrer sans le service de gestion du fournisseur.
  • Les documents examinés décrivent des capacités utiles. Ils ne constituent ni un essai de sortie ni une démonstration de reprise autonome ; cette limite documentaire ne signifie pas que ces capacités sont absentes.

Un dépôt au choix, mais quelle chaîne de restauration ?

Safe Swiss Cloud décrit un service Business Backup dont la destination n’est pas imposée au seul stockage du fournisseur. Sa présentation du produit énumère notamment son stockage objet compatible S3, AWS S3, FTP, SFTP, SWIFT et des systèmes de fichiers montés. Elle précise aussi que le client peut utiliser son propre stockage de sauvegarde sur site.

Ce choix mérite d’être reconnu. Il permet de décider où conserver une copie, plutôt que de confondre automatiquement service de sauvegarde et dépôt unique. Mais la présence d’une copie dans un espace choisi par le client ne répond pas à toutes les questions de reprise. Il reste à savoir qui dispose des accès utilisables, des clés nécessaires, des métadonnées et du logiciel permettant de reconstruire les données.

La distinction est concrète : posséder les octets, pouvoir déclencher une opération et pouvoir rétablir une application sont trois capacités différentes. Une solution peut assurer les deux premières sans que les documents disponibles démontrent la troisième dans un scénario où son service de gestion serait indisponible. C’est une question à vérifier, non un incident constaté chez Safe Swiss Cloud.

Le libre-service ne décrit pas tous les chemins de secours

Selon la description de Business Backup, le client peut restaurer des fichiers ou des sauvegardes complètes depuis une interface web en libre-service. L’accès au serveur de gestion des sauvegardes est protégé par une authentification à deux facteurs. Le même document annonce un chiffrement AES-256 en transit et au repos, ainsi que de la compression et une déduplication côté client.

Ces éléments décrivent des fonctions de sécurité et d’exploitation. Ils ne précisent pas, dans les matériaux examinés, si le client détient exclusivement les clés de chiffrement ou s’il dispose d’une chaîne de restauration utilisable indépendamment du service de gestion. La robustesse d’un algorithme et la disponibilité de la personne ou du système autorisé à utiliser les clés sont deux sujets distincts.

L’entreprise recommande également de tester une restauration après la configuration. Elle indique que l’opération peut prendre plus de 15 minutes selon la taille de la sauvegarde et conseille de restaurer une image sur une nouvelle machine — serveur, machine virtuelle ou poste de travail — pour ne pas détruire la source. Ce sont des consignes utiles, pas un délai garanti de remise en service.

Un essai effectué lorsque tous les composants habituels fonctionnent renseigne sur le parcours normal. Un essai autorisé qui définit précisément un composant de gestion indisponible répond à une exigence plus forte. Il ne faut pas traiter cette exigence d’indépendance comme une obligation implicite de tout service administré : un client peut choisir de déléguer la reprise. Il doit alors savoir ce qu’il délègue.

Le miroir en 24 heures ne fixe pas le délai de reprise

La FAQ Business Backup indique que le stockage objet par défaut de Safe Swiss Cloud est automatiquement répliqué entre deux centres de données de l’entreprise dans un délai de 24 heures. Cette indication porte sur cette configuration de stockage. Elle ne doit pas être étendue aux destinations externes proposées au client.

Elle ne suffit pas non plus à fixer le temps nécessaire au redémarrage d’une application. Répliquer une sauvegarde et remettre un service en état de fonctionner sont des opérations différentes. Il faut encore pouvoir accéder à la copie, la reconstruire et vérifier que l’application restaurée est exploitable.

Le délai de réplication ne constitue pas, à lui seul, un engagement sur la quantité de données applicatives susceptibles d’être perdues. Pour répondre à cette question, il faudrait notamment connaître le point de sauvegarde effectivement récupéré et les dernières transactions présentes après restauration. Remplacer ces observations par le seul chiffre de 24 heures ferait dire à la FAQ davantage qu’elle n’établit.

Une sortie annoncée n’est pas encore une sortie mesurée

La FAQ générale de Safe Swiss Cloud affirme explicitement que les clients peuvent déplacer eux-mêmes leurs charges de travail vers son cloud et hors de celui-ci. Il s’agit bien d’une capacité annoncée dans les deux sens, et non d’une simple promesse de faciliter l’arrivée de nouveaux clients.

La partie détaillée consacrée à la migration entrante apporte toutefois une précision dont le périmètre compte. Pour la méthode élémentaire consistant à exporter puis importer les volumes d’une machine virtuelle, la FAQ avertit que des volumes supérieurs à 100 Go peuvent demander des heures de transfert, pendant lesquelles le service reste indisponible pour les utilisateurs. Elle présente aussi la réplication et la synchronisation comme une autre approche de migration.

Cet avertissement concerne l’arrivée de machines existantes chez Safe Swiss Cloud. Ce n’est ni une mesure du temps de sortie, ni une limite universelle du service, ni le résultat d’un test client présenté ici. Les documents examinés ne fournissent pas un parcours de départ complet avec inventaire des formats exportables, prérequis, coûts et durée représentative.

La bonne conclusion n’est donc pas que le client ne peut pas partir. C’est que la possibilité déclarée de partir doit encore être rapprochée d’une procédure exécutable pour sa propre charge de travail. Exporter un volume ne démontre pas, en soi, que l’application fonctionnera dans l’environnement d’arrivée.

Soixante jours pour supprimer ne signifie pas soixante jours pour exporter

Les conditions générales publiées prévoient une résiliation prenant effet à la fin d’un mois civil et une facturation mensuelle jusqu’à résiliation écrite. Elles indiquent aussi : « The account data will be deleted within 60 days of termination. » Autrement dit, les « données du compte » doivent être supprimées dans les 60 jours suivant la résiliation.

Deux raccourcis seraient trompeurs. D’abord, « dans les 60 jours » ne signifie pas « au terme de 60 jours ». Ensuite, une échéance de suppression ne garantit pas un accès continu pendant toute cette période. Le passage examiné ne promet pas expressément une assistance à l’export après la résiliation. Le périmètre exact de l’expression « account data » — notamment son application aux volumes de machines virtuelles, aux sauvegardes et au stockage objet — n’est pas établi par cette seule formulation.

Les mêmes conditions décrivent le niveau de service par défaut comme fourni « as is », en libre-service, avec une assistance relative à la disponibilité fondée sur le principe de « meilleurs efforts » (« best effort »), et proposent des formules d’assistance supplémentaires. Elles ne remplacent pas l’examen du contrat effectivement souscrit. Il serait tout aussi incorrect d’appliquer à Business Backup des engagements propres à un autre produit.

Pour préparer un départ, la conséquence pratique est simple : obtenir par écrit les droits d’accès et d’export qui subsistent après la fin du service, leur durée et leur périmètre, plutôt que de déduire une fenêtre de migration de la date limite de suppression.

Ce que cette lecture permet de conclure

Les quatre sources sont des documents publiés par Safe Swiss Cloud : une présentation de produit, deux FAQ et les conditions générales. Aucun test indépendant de restauration ou de sortie n’a été réalisé pour cette analyse, et aucun accord propre à un client n’a été examiné. Les dates de publication des pages ne sont pas établies ; il ne s’agit donc pas d’annoncer un changement récent de l’offre.

Ces documents soutiennent une conclusion positive mais circonscrite : le fournisseur décrit plusieurs destinations de sauvegarde et des opérations accessibles au client, dont le déplacement des charges dans les deux sens. Ils ne prouvent ni ne réfutent une reprise de bout en bout indépendante de ses composants de gestion. Pour passer du choix annoncé au contrôle démontré, il manque un résultat observable : une application restaurée dans les conditions de panne ou de départ que le client veut réellement pouvoir affronter.