REGRU « Domain names registrar REG.RU », Ltd vend de la capacité hébergée qui dépend encore des baies, du transit et des fenêtres de réparation

Résumé

• REG.RU expose une surface opérationnelle réelle: le registre des identifiants de registraire IANA l’accrédite, le routage observé par RIPE montre des centaines d’annonces IPv4 et IPv6 derrière AS197695, et le catalogue de la marque propose de l’hébergement mutualisé, des machines virtuelles, des serveurs bare metal, du stockage, des bases de données, Kubernetes et de la colocation. Cela va au-delà d’une simple vitrine, mais cela ne prouve pas que la société registraire nommée possède chaque installation ou exploite elle-même chaque couche de produit.
• La résilience n’est pas héritée de la taille du portefeuille. REG.RU publie plusieurs emplacements en Russie, des outils de sauvegarde et de migration, des adresses flottantes, des réseaux privés et un objectif de service cloud à 99,95 %, mais c’est le choix du site, la séparation des sauvegardes, les exclusions de maintenance, le remplacement matériel, l’escalade du support et la conception applicative inter-sites qui déterminent la récupération effective pour les clients.
• La conclusion opérationnelle la plus claire est donc conditionnelle. Le réseau et l’inventaire actif des produits justifient de traiter REG.RU comme un fournisseur d’infrastructure opérationnelle. La propriété des installations, la capacité par service, la réplication inter-régionale et l’historique des performances en incident ne sont que partiellement visibles, de sorte qu’un client doit vérifier l’entité contractante exacte, l’emplacement, l’objectif de récupération, la conception de routage et la procédure d’exportation pour chaque service avant de considérer un déploiement REG.RU comme redondant.

Un compte de registraire est devenu une surface de contrôle d’infrastructure

REG.RU est toujours reconnaissable comme un registraire de noms de domaine. Leregistre des identifiants de registraire IANArépertorie « Registrar of Domain Names REG.RU LLC » comme accrédité sous l’identifiant 1606 et renvoie vers son service RDAP. Ses propresdétails d’entrepriseidentifient la société à responsabilité limitée russe dont l’appellation en anglais figure dans l’entrée du répertoire, avec l’identifiant fiscal 7733568767 et une adresse légale à Moscou. Ces faits établissent le sujet de ce profil de manière plus sûre que la seule marque.

La proposition client s’étend cependant bien au-delà de l’enregistrement. Lapage entreprisede REG.RU décrit une gamme cloud basée sur OpenStack et VMware, des serveurs dédiés et de la colocation. Lecatalogue de services REG.Cloudactuel répertorie des machines virtuelles, des serveurs bare metal physiques, des bases de données gérées, Kubernetes, du stockage compatible S3, des environnements privés OpenStack et VMware, des services réseau et de l’espace en baie. Une petite organisation peut ainsi acheter le nom, le DNS faisant autorité, l’hébergement du site web et la capacité serveur via les surfaces REG.RU liées. Un client plus important peut louer de l’équipement physique ou le combiner avec des ressources virtuelles et des services gérés.

Ce regroupement a des conséquences opérationnelles. Un compte de registraire n’est plus simplement l’endroit où une date de renouvellement est stockée. Il peut devenir le lieu où se rencontrent les noms publics, les enregistrements d’adresses, les commandes de calcul, les politiques de sauvegarde, les tickets de support et les soldes de paiement. La commodité réduit le coût de mise en ligne d’un service. Elle concentre également l’autorité administrative.

Une perte d’accès, une erreur de paiement, une modification DNS incorrecte ou un incident de sécurité au niveau du compte peut affecter plusieurs couches même lorsque les machines sous-jacentes restent saines.

Voici la première distinction que les clients doivent préserver: l’intégration commerciale n’est pas une redondance technique. Acheter un domaine et un serveur auprès de la même famille peut simplifier la configuration et le support. Cela ne crée pas un deuxième fournisseur de DNS faisant autorité, un deuxième cloud, une copie indépendante des données ou un identifiant administratif distinct. Une conception de récupération doit délibérément créer ces séparations.

La réciproque est également importante. Le large catalogue ne doit pas être considéré comme une simple liste d’étiquettes revendues. REG.RU dispose de ressources réseau observables, publie des emplacements d’installations spécifiques, annonce des configurations physiques en stock et documente ses propres contrôles opérationnels. Il s’agit d’identifier où ces preuves sont solides et où une déclaration au niveau de la marque est censée porter plus de poids qu’elle ne peut en supporter.

Une seule marque ne signifie pas un seul opérateur ni un seul modèle de propriété

La frontière juridique est particulièrement importante ici car les surfaces publiques de REG.RU utilisent un seul nom pour plusieurs types de services. Lesrègles du siteidentifient « REG.RU Domains Hosting » LLC comme l’administrateur des propriétés web et désignent « Domain names registrar REG.RU » Ltd comme un partenaire qui fournit des services dans le cadre de ses propres contrats clients. Par ailleurs, lesrègles de supportdu registraire décrivent le support fourni par la société registraire pour l’enregistrement, l’hébergement et d’autres services. Lesconditions promotionnelles récentes pour le cloud GPUont également désigné la société registraire comme organisateur. Les documents montrent une intégration opérationnelle étroite, mais ils ne permettent pas de traiter les deux personnes morales comme interchangeables.

La même prudence s’applique aux bâtiments. REG.RU indique utiliser un mélange de capacités de centres de données propres et connectées. Ses pages produits nomment des installations commerciales ainsi que des sites sous la marque REG.RU. Lapage VPSidentifie des emplacements incluant KIAEHOUSE sur le site de l’Institut Kourtchatov, SafeData, Medvedkovo-2, DataPro, une installation sur l’autoroute de Varsovie, le Data Centre No. 1 à Saint-Pétersbourg et la Vallée de Zhiguli à Togliatti. Une annonce de juin 2026 indique qu’une troisième région cloud de Moscou a été ouverte dans l’installation Magistralny-1 de Datahouse. Ces noms indiquent des locations, des accords d’hébergement ou d’autres dépendances vis-à-vis des installations, en plus de tout bâtiment que le groupe pourrait posséder directement.

Ce n’est pas une faiblesse propre à REG.RU. La plupart des services d’infrastructure sont des activités à plusieurs couches. Un fournisseur peut posséder des serveurs, louer des cages ou des baies, contracter pour l’alimentation électrique, acheter du transit et utiliser des installations tierces tout en exploitant le service client. Mais chaque couche modifie la frontière d’incident. Un opérateur d’installation contrôle l’alimentation électrique et le refroidissement. Un opérateur télécom contrôle un circuit externe.

REG.RU contrôle sa flotte de serveurs, la virtualisation, la configuration du service et la réponse client à des degrés divers. Le client contrôle l’application, les identifiants, le placement des données et une grande partie du plan de récupération.

La question pratique d’approvisionnement est donc plus précise que « REG.RU possède-t-il ses centres de données? » C’est: pour ce service commandé à cet emplacement choisi, qui possède le serveur, qui assure l’intervention à distance, qui contrôle la périphérie réseau, qui maintient l’hyperviseur et le stockage, et quelle société doit la réparation contractuelle? Une machine bare metal annoncée comme physiquement disponible est un arrangement différent d’une machine virtuelle sur un cluster partagé, et les deux diffèrent d’un serveur appartenant au client et placé en colocation.

La documentation de REG.RU est utile car elle révèle des parties de cette division, mais elle ne publie pas une matrice complète de propriété et de responsabilité pour chaque produit et emplacement. Tant qu’un contrat ou un cahier des charges technique ne fournit pas cette matrice, les déclarations de propriété au niveau du portefeuille doivent être considérées comme non vérifiées. Le service peut être réel et fonctionner sans que chaque baie ne soit un actif de l’entité répertoriée.

Le parc physique est russe, distribué et inégalement décrit

Leguide d’emplacement d’hébergementde REG.RU donne cinq adresses principales: trois à Moscou, une à Saint-Pétersbourg et une à Togliatti. Il indique que l’hébergement mutualisé se trouve sur le site de la place Kourtchatov à Moscou. Il précise également que les installations disposent d’une alimentation de secours, de refroidissement et d’une sécurité à plusieurs niveaux. Il s’agit d’une preuve utile spécifique au service car elle lie l’hébergement mutualisé à un lieu nommé plutôt que de simplement dire « Russie ».

Le catalogue plus large du fournisseur est plus étendu. La page VPS fournit des noms d’installations, des chiffres de puissance, des nombres de baies et des types de services. Elle décrit le Data Centre No. 1 sur la rue Predportovaya à Saint-Pétersbourg comme un site de conception Tier III avec 2 MW et 260 baies, et la Vallée de Zhiguli dans la région de Samara comme certifiée selon les normes Uptime Institute Tier Design et Tier Facility. La page inclut également des sites moscovites avec différentes combinaisons de bare metal et de cloud public. Une vérification indépendante est possible pour au moins une de ces dépendances: lapage de contact propre de Data Centre No. 1donne la même adresse rue Predportovaya, confirmant que l’emplacement de REG.RU à Saint-Pétersbourg correspond à une installation exploitée séparément.

La déclaration la plus récente sur le portefeuille de REG.RU est plus étoffée. En annonçant les instances NVIDIA Blackwell en juin 2026, la société a déclaré que son cloud de marque comptait dix centres de données, 85,5 MW de capacité agrégée et 300 Gbit/s de débit sur canaux optiques. Elle a décrit la nouvelle région Moscou-3 chezDatahouse Magistralny-1comme un contour d’infrastructure indépendant avec son propre cluster OpenStack et ses hyperviseurs. L’annonce attribue 1 100 baies, jusqu’à 15 kW par baie et un objectif de disponibilité de 99,99 % pour ce site.

Ces chiffres témoignent de l’échelle que REG.RU commercialise, pas d’une mesure directe de la capacité disponible pour un client particulier. L’alimentation électrique totale d’une installation inclut l’espace utilisé par d’autres locataires. Un nombre de baies ne dit rien sur le nombre de baies que REG.RU occupe. Une densité maximale par baie ne montre pas la charge moyenne déployée. Le débit sur canaux optiques n’est pas la même chose qu’un transit client non congestionné à chaque emplacement.

Dix sites connectés n’impliquent pas que chaque service puisse fonctionner sur les dix, ni que les données soient automatiquement répliquées entre eux.

Les preuves les plus utiles pour la décision apparaissent dans le parcours de commande. L’inventaire de serveurs dédiésde REG.RU permet aux clients de filtrer les machines physiques par plusieurs emplacements nommés à Moscou, et les fiches individuelles identifient un processeur, de la mémoire, une configuration de disques, une option de gestion à distance, un port réseau et l’emplacement. Il s’agit de capacité installée ou commandable, bien qu’il demeure un inventaire changeant plutôt qu’un total de flotte audité. La documentation de commande cloud indique de même aux clients de choisir une région de placement. Ces emplacements sélectionnables importent plus qu’un grand chiffre de parc agrégé car ils définissent où un client peut effectivement placer une charge de travail aujourd’hui.

Le résultat est une carte à plusieurs couches. L’hébergement mutualisé a une adresse moscovite principale divulguée. Le bare metal apparaît sur plusieurs sites nommés. Les services cloud gérés exposent un ensemble plus restreint de régions ou de zones qui évolue selon le produit. Saint-Pétersbourg et Togliatti élargissent le choix géographique, tandis que les nouveaux sites moscovites élargissent la capacité métropolitaine. Rien de tout cela ne prouve en soi une redondance synchrone entre les villes, les bâtiments ou les clusters.

La capacité installée n’est pas la capacité utilisable

Le marketing cloud convertit les machines physiques en unités simples: vCPU, mémoire et stockage. Cette conversion cache les décisions d’utilisation et de maintenance qui déterminent si une unité demandée est disponible lorsque la demande augmente. Le catalogue de REG.RU montre une gamme substantielle, mais la distinction entre capacité installée et capacité utilisable reste essentielle.

Pour le bare metal, la capacité utilisable est visible sous la forme de configurations en stock. Lapage des serveurs dédiéspropose des options AMD EPYC, Intel Xeon, NVMe, disques durs et GPU et indique que le matériel est en stock. Les offres individuelles montrent une machine spécifique et précisent que la mise à disposition commence à partir de 45 minutes pour de nombreux serveurs. C’est plus solide qu’une page produit conceptuelle: cela suggère un inventaire actif et un mécanisme de commande. Cependant, le stock change, et une pièce de rechange n’est pas garantie simplement parce qu’une machine similaire apparaît dans le catalogue. Les clients ayant des objectifs de restauration stricts doivent savoir si les disques, alimentations, cartes mères et accélérateurs défaillants disposent de pièces de rechange sur place dans l’installation sélectionnée et quelles substitutions sont autorisées.

Pour les machines virtuelles, la capacité utilisable dépend de la marge du cluster, des performances de stockage, des limites du planificateur et de la disponibilité réseau. Leguide de commande de serveurs cloudde REG.RU montre des configurations standard, haute fréquence et pour données réglementées, ainsi que des images GPU. Une annonce matérielle de juin 2026 va plus loin, en nommant des systèmes Supermicro, des processeurs AMD EPYC 9554 et des accélérateurs RTX 6000 Pro Blackwell Server Edition pour la région Moscou-3. Cette spécificité étaye l’existence d’un nouveau parc matériel réel. Elle ne divulgue pas pour autant le surbooking, la marge libre ou le nombre d’hôtes installés.

Le stockage présente son propre écart entre une revendication produit et la capacité récupérable. Lapage de stockage compatible S3indique que les objets sont conservés en trois copies et que le fournisseur est responsable de l’infrastructure, de la réplication, de la mise à l’échelle et de la disponibilité. Trois copies peuvent protéger contre certaines pannes de périphériques ou de nœuds. La page n’indique toutefois pas explicitement que ces copies se trouvent dans trois bâtiments ou zones de panne indépendants. Trois réplicas dans un même site ne constituent pas une copie de reprise après sinistre régionale. Un client doit demander la politique de placement, les limites des domaines de panne, le comportement de versionnage et le processus de récupération plutôt que de supposer que « trois copies » signifie « trois régions ».

Même la capacité électrique d’une installation est conditionnelle. Un bâtiment de 36 MW peut avoir une infrastructure solide alors que la surface louée par le fournisseur, la puissance contractuelle et les ports réseau installés sont bien moindres. Une limite de conception de 15 kW par baie ne signifie pas que chaque baie dispose de cette charge provisionnée. L’unité utile pour un client n’est pas la puissance nominale du campus; c’est le contrat de capacité attaché à un service choisi et la capacité du fournisseur à en fournir davantage lors d’une défaillance ailleurs.

C’est pourquoi les tests de basculement doivent inclure la rareté. Si un cluster moscovite tombe en panne, le second emplacement peut-il accepter la charge de travail déplacée, et pas seulement exécuter une petite machine de secours? Si un hôte GPU spécialisé tombe en panne, un accélérateur équivalent est-il gardé en réserve? Si un pool de stockage devient indisponible, le pool survivant peut-il servir à la fois le trafic normal et le trafic de récupération? Les documents publics ne répondent pas à ces questions, elles relèvent donc de la diligence technique.

AS197695 est le signe indépendant d’exploitation le plus clair

L’enregistrement réseau fournit la preuve la plus solide que l’entité répertoriée exploite l’infrastructure plutôt qu’elle ne se contente de vendre le service d’une autre société. L’enregistrement RIPE et les observations de routage publiques associent AS197695, AS-REGRU, à « Domain names registrar REG.RU », Ltd. Uninstantané BGP.Toolsdécrit le réseau comme actif et orienté contenu, et montre des centaines de préfixes IPv4 émis ainsi que des annonces IPv6. Uneréponse RIPEstat sur les préfixes annoncésa observé 477 annonces le 12 juillet 2026: 453 préfixes IPv4 et 24 IPv6, en excluant les routes à très faible visibilité de collecteur.

L’étendue de cette surface est significative. Elle est cohérente avec un fournisseur d’hébergement desservant de nombreux blocs d’adresses et services clients. À titre d’exemple, le préfixe176.99.13.0/24est émis par AS197695 et contient des adresses utilisées par les serveurs de noms de REG.RU. Le domaine web principal de la société se résout également dans le même système autonome selon lavue DNS de Hurricane Electric. Ces observations relient les surfaces corporate, DNS et d’hébergement à un domaine de routage opéré.

Laréponse des voisins ASN de RIPEa montré de nombreux numéros AS adjacents dans les chemins observés à la même date, notamment TransTeleCom, EDINAYA SET, Hurricane Electric, OBIT, RETN et ER-Telecom entre autres. Cela indique une connectivité externe variée dans la vue de routage mondiale. Cela ne prouve pas que chaque installation de REG.RU a des accès physiquement diversifiés, que chaque réseau nommé est un amont payant, ou que deux circuits ne partagent pas la même gaine. La classification de chemin gauche/droite de RIPE est une observation sur la position dans le chemin AS, pas une étiquette de relation commerciale.

Deux réserves s’imposent également. Premièrement, AS43146 est enregistré pour la même organisation maisBGP.Tools le signalecomme absent de la table mondiale actuelle. Un système autonome enregistré ne constitue pas une preuve de service actif; AS197695 est le signal opérationnel pertinent. Deuxièmement, une requête aupoint d’accès réseau PeeringDBn’a retourné aucun enregistrement réseau public pour AS197695. La participation à PeeringDB est volontaire, de sorte que l’absence ne prouve pas une connectivité médiocre. Cela signifie que le dossier public ne contient pas de matrice d’installations et d’échanges tenue par le fournisseur, ce qui pourrait autrement aider à vérifier où REG.RU effectue son peering.

L’échelle du réseau n’efface pas non plus la concentration. Des centaines de préfixes peuvent traverser un même système autonome et partager une politique de routage, des systèmes d’atténuation ou du personnel opérationnel. Les clients qui utilisent REG.RU pour le DNS faisant autorité, l’hébergement et l’origine de l’application peuvent rester dépendants du même compte et réseau même lorsque les adresses IP diffèrent. Une véritable diversité de routes exige des tests de chemin depuis les réseaux d’utilisateurs concernés et la confirmation des circuits physiques sur chaque site sélectionné.

La promesse de niveau de service laisse place aux fenêtres de maintenance

L’accord de niveau de service cloud de REG.RU est particulièrement révélateur de la différence entre un objectif de disponibilité et un service ininterrompu. L’accord en vigueur au 14 avril 2026fixe des objectifs mensuels de 99,95 % pour les services d’infrastructure, de réseau et de centre de données tels que l’électricité, le chauffage, la ventilation et le refroidissement. Dans un mois de 730 heures, 0,05 % correspond à environ 21,9 minutes, avant prise en compte des exclusions.

Les exclusions sont importantes. L’accord autorise des interruptions pour travaux planifiés totalisant jusqu’à 48 heures par an et pas plus de six heures par mois, avec un préavis d’au moins 24 heures. Les travaux urgents peuvent durer aussi longtemps que nécessaire pour supprimer ou prévenir une urgence, avec un préavis immédiat avant l’interruption. L’accord précise que ces interruptions de maintenance ne comptent pas comme indisponibilité normale du service.

Il exclut également plusieurs conditions imputables au client ou externes et prévoit un traitement sous forme de crédits de service pour les indisponibilités éligibles plutôt qu’une indemnisation pour les pertes commerciales plus larges du client.

Cela ne rend pas l’objectif dénué de sens. Un objectif écrit couvrant le calcul, le réseau et les systèmes d’installation constitue une référence utile. Il identifie un recours et oblige le fournisseur à mesurer la disponibilité. Mais cela change l’interprétation technique. Un client ne peut pas convertir 99,95 % en une promesse qu’aucune fenêtre de maintenance de six heures ne se produira. Une application qui ne peut pas tolérer la fenêtre autorisée a besoin d’un deuxième emplacement de service et d’une méthode testée pour déplacer le trafic.

Les pages produits utilisent parfois des chiffres différents. Le guide d’emplacement de l’hébergement mutualisé annonce 99,9 % de disponibilité, tandis que l’annonce Moscou-3 attribue 99,99 % à l’installation. Ces pourcentages font référence à des périmètres différents et ne doivent pas être mélangés. Une conception ou un objectif d’installation n’est pas la même chose que la disponibilité applicative. Un serveur peut rester sous tension alors que le stockage, un hyperviseur, une route, le DNS ou le logiciel client tombent en panne.

À l’inverse, une plateforme peut maintenir une application en ligne pendant une panne d’hôte si la charge de travail est correctement répartie.

La transparence sur les incidents publics est mince. Aucun hôte de statut public clairement identifiable pour REG.RU n’a été trouvé au cours de cette revue, et l’archive d’actualités de la société ne constitue pas un historique structuré des incidents. Les moniteurs tiers ne fournissent que des signaux faibles. Par exemple, lapage de disponibilité de Hosters.rua rapporté des vérifications du site web public de REG.RU, et non du parc cloud client, etWho.ismesure de même le point d’accès corporate. Une sonde échouée pourrait refléter un filtrage, un problème de redirection ou le site web lui-même; une sonde réussie ne dit rien sur une VM client dans une autre région. Ces observations ne peuvent ni valider ni infirmer la performance du SLA cloud.

Une norme de transparence plus solide inclurait l’état par service, les étiquettes de région, les heures de début et de rétablissement des incidents, les composants affectés et des explications post-incident. En son absence, les clients devraient demander des rapports de disponibilité historiques et demander comment les travaux planifiés, les travaux urgents et la dégradation partielle sont pris en compte dans les mesures de service.

La panne matérielle ramène l’abstraction du cloud à l’inventaire et à la main-d’œuvre

Une machine virtuelle semble indépendante d’un serveur particulier jusqu’à ce qu’un composant physique tombe en panne. Un service bare metal ne cache jamais cette dépendance. La documentation de REG.RU montre à la fois les avantages et les limites de son modèle d’exploitation matérielle.

Le catalogue dédié inclut le contrôle à distance, la protection DDoS, un port réseau, l’installation du système d’exploitation et le « remplacement opérationnel » des pannes. Songuide IPMIexplique que certains serveurs exposent une gestion hors bande indépendante et que KVM est disponible là où IPMI ne l’est pas. Un client peut utiliser ce canal pour inspecter les problèmes de démarrage, redémarrer une machine ou installer un système d’exploitation même lorsque le système d’exploitation principal est indisponible. Cela réduit la dépendance au support pour certaines pannes.

Cela ne remplace pas l’intervention physique. Une carte mère, un périphérique de stockage, une alimentation ou une interface réseau défaillante nécessite toujours une personne et une pièce de rechange. Le « remplacement opérationnel » n’est pas un objectif de temps de remplacement publié. Le fournisseur peut rétablir le service en remplaçant un composant, en déplaçant des disques, en fournissant un serveur différent ou en reconstruisant l’environnement d’exploitation, et ces options ont des conséquences différentes pour l’intégrité des données et le temps d’arrêt.

La génération du matériel affecte également la récupération. Le catalogue contient à la fois des systèmes EPYC et GPU récents et d’anciennes configurations Xeon. Cette gamme est économiquement rationnelle: les clients échangent performances et ancienneté contre prix. Mais une politique de remplacement doit définir si le client reçoit des pièces identiques, des performances équivalentes ou tout substitut disponible. Les interfaces de mémoire et de disque anciennes peuvent être plus difficiles à remplacer rapidement que le stock actuel. Les GPU spécialisés créent une contrainte d’inventaire encore plus stricte.

Pour le cloud virtuel, le fournisseur peut déplacer ou recréer un invité sur un autre hôte uniquement si le cluster, le stockage et la conception réseau le permettent et si une capacité de réserve existe. REG.RU décrit son cloud comme tolérant aux pannes, mais les pages produits publiques ne divulguent pas la politique d’évacuation des hôtes ni les domaines de panne de chaque service. La documentation Kubernetes géré indique qu’un cluster tolérant aux pannes peut basculer vers un nœud maître de réserve, ce qui protège ce composant de contrôle.

Cela ne rend pas automatiquement les charges de travail client multi-sites ni ne garantit que les données avec état survivent à une perte d’installation.

La conception applicative du client reste donc déterminante. Les services sans état peuvent être recréés à partir d’images et de configuration plus facilement qu’une base de données mutable unique. Une base de données bare metal avec des disques locaux a besoin de réplicas ou de sauvegardes récupérables ailleurs. Une machine virtuelle avec un instantané dans le même domaine de stockage peut toujours être exposée à une défaillance du domaine de stockage. La marque peut fournir des composants utiles, mais aucune sélection de catalogue ne transforme une instance unique en une architecture de récupération.

Les sauvegardes sont des produits, pas une preuve de récupérabilité

REG.RU propose plusieurs mécanismes de sauvegarde, et les différences entre eux sont importantes. L’hébergement mutualisé reçoit des sauvegardes automatiques quotidiennes, selon leguide de sauvegarde d’hébergement. Le guide indique que les copies sont conservées pendant 30 jours, sont effectuées pendant la nuit et deviennent disponibles le lendemain. Cela convient à de nombreux sites web, mais implique un écart de point de récupération potentiellement long pour des données changeant fréquemment.

La sauvegarde de serveur cloud est activée et facturée séparément. Leguide de sauvegarde cloudindique que la politique par défaut conserve trois copies, dont une hebdomadaire et les deux dernières versions, avec une création quotidienne. Les clients peuvent modifier les politiques de rétention et restaurer un serveur à partir d’une copie enregistrée. La restauration peut nécessiter la mise à jour des enregistrements de domaine lorsqu’une adresse change. Ce dernier détail est important sur le plan opérationnel: la récupération du calcul et la récupération du trafic peuvent être des étapes distinctes.

Les serveurs dédiés offrent plus de choix. Lapage produit de sauvegardede REG.RU décrit des copies quotidiennes au niveau fichiers pour Linux, des options Veeam, du stockage FTP, S3 et des conceptions privées. Elle indique que les sauvegardes sont stockées séparément du serveur, et sa description Linux standard conserve les sept derniers jours. Des conceptions plus élaborées peuvent placer des copies récentes sur disque et des archives plus longues sur bande. « Séparément du serveur », cependant, ne signifie pas nécessairement « dans un bâtiment séparé » ou « en dehors du fournisseur ». Les clients ont besoin de l’emplacement exact et de la séparation administrative.

Le service S3 ajoute une autre option et prend en charge une interface ouverte. Un point d’accès compatible S3 peut rendre l’intégration applicative et le transfert de données plus faciles qu’un produit de stockage entièrement propriétaire. REG.RU indique que le service conserve trois réplicas et permet la gestion via l’API S3 et Terraform. Cela favorise la portabilité au niveau objet. Cela ne prouve pas qu’un grand ensemble de données puisse être exporté dans le délai requis, que le versionnage soit activé, ou que les réplicas internes du fournisseur protègent contre la suppression de compte ou des clés d’accès compromises.

Un test de récupération crédible comporte quatre parties. La copie doit contenir les données requises. Elle doit être isolée de la défaillance à l’origine. Le client doit pouvoir s’authentifier et la récupérer pendant un incident. Le système restauré doit passer un contrôle d’intégrité au niveau applicatif. Les messages de fin de sauvegarde n’établissent que la première partie, et imparfaitement.

C’est particulièrement important lorsque le domaine, le DNS, le calcul et la sauvegarde utilisent un seul compte. Un attaquant ou un administrateur disposant de droits étendus peut être en mesure de modifier des enregistrements, de supprimer des machines et d’effacer des copies. Les clients doivent séparer les identifiants, utiliser des copies indépendantes pour les données critiques, protéger la suppression par des contrôles de rétention lorsque disponibles et s’entraîner à la restauration dans un autre environnement. La présence d’un bouton de sauvegarde est précieuse, mais une restauration chronométrée est la preuve qui compte.

Le choix multi-site n’est pas un service multi-site automatique

REG.RU a ajouté un choix d’emplacement significatif. Une annonce de 2023 décrivait unsite cloud à Saint-Pétersbourgaux côtés de trois centres de données moscovites. Une mise à jour opérationnelle de 2024 indiquait que la société avait connecté un nouveau site à Togliatti tout en élargissant les produits cloud. En mars 2026, REG.Cloud a annoncé undeuxième emplacement moscovite pour les bases de données gérées, permettant aux clients de déployer DBaaS dans Moscou-1 ou Moscou-2 et de restaurer dans un nouveau cluster. En juin, Moscou-3 a ajouté un contour OpenStack distinct.

Il ne s’agit pas toujours du même type de redondance. Une deuxième installation à Moscou peut réduire l’exposition à une panne de bâtiment, à une maintenance locale ou à un incident de cluster. Elle reste exposée aux risques métropolitains, aux contrôles de réseau régionaux et à certains personnels ou systèmes de contrôle partagés. Un déploiement à Togliatti ou à Saint-Pétersbourg augmente la séparation géographique mais peut offrir un ensemble de produits, un pool de capacité ou un profil de latence différents. Les documents publics ne prétendent pas que chaque service peut basculer automatiquement sur tous ces sites.

La mise à jour DBaaS est un bon exemple de progrès précis mais limité. Elle indique que les clients peuvent sélectionner l’un des deux emplacements moscovites, restaurer une sauvegarde dans un nouveau cluster sans arrêter l’original, et utiliser la récupération à un point dans le temps pour PostgreSQL. Ces capacités réduisent le coût des tests de récupération et du passage à une instance propre. L’annonce indique qu’un second emplacement améliore la répartition de charge et la conception résiliente; elle ne dit pas que les bases de données sont répliquées de manière synchrone sur les deux emplacements par défaut.

Les adresses publiques flottantes ont également une portée limitée. Leguide d’IP flottantesde REG.RU indique qu’une adresse peut être attachée à un périphérique au sein d’un même sous-réseau privé. C’est utile pour le basculement entre instances sur ce réseau. Cela ne constitue pas la preuve que la même adresse peut être déplacée vers une autre région ou survivre à la perte de la couche de contrôle réseau. De même, les réseaux privés relient des ressources, mais ils nécessitent une conception de routage, d’adressage et de sécurité de la part du client.

Kubernetes géré offre des nœuds de plan de contrôle de réserve, et S3 fournit une réplication, mais chacun protège un composant spécifique. La résilience n’émerge que lorsque les dépendances de l’application sont alignées: calcul dans plus d’un domaine de panne, données répliquées ou restaurables, direction du trafic indépendante du site défaillant, secrets disponibles, capacité réservée et opérateurs capables d’exécuter le basculement.

Les clients doivent également demander si la région cible peut être sélectionnée au moment de la commande pour chaque composant. Une machine virtuelle dans Moscou-2 associée à un stockage disponible uniquement dans Moscou-1 peut conserver une dépendance inter-sites cachée. Une base de données gérée peut prendre en charge deux emplacements tandis que le dépôt de sauvegarde reste partagé. La documentation publique atteste de l’existence de choix; elle ne fournit pas une carte des dépendances complète.

La diversité du transit doit être prouvée à la périphérie du service

Les voisins observés et les centaines de préfixes d’AS197695 rendent improbable un réseau à opérateur unique au niveau du système autonome. REG.RU annonce également une capacité de réseau privé d’environ 200 Gbit/s et des canaux d’accès dupliqués de 40 Gbit/s sur sa page VPS, tandis que la déclaration de portefeuille plus récente cite 300 Gbit/s de canaux optiques. Ces chiffres indiquent un réseau substantiel, mais ils ne remplacent pas une preuve de route par site.

Le réseau peut tomber en panne à plusieurs couches. Un commutateur haut de baie peut isoler un groupe de serveurs. Une interconnexion d’installation peut tomber en panne alors que le système autonome plus large reste visible. Une fuite de route ou une erreur de filtrage peut rendre certains préfixes inaccessibles depuis certains réseaux. Les contrôles DDoS peuvent protéger la capacité tout en introduisant des faux positifs. Un pare-feu côté client ou un changement d’adresse peut ressembler à une panne du fournisseur.

Le DNS peut continuer à répondre avec une origine inaccessible, ou l’origine peut fonctionner alors que le compte REG.RU utilisé pour modifier le DNS est indisponible.

Pour un client, le test pertinent part de l’adresse applicative, et non de l’ASN en une du fournisseur. Les observations de route doivent être collectées auprès des populations d’utilisateurs et depuis plus d’un réseau externe. Les traceroutes ne prouvent pas la diversité physique, mais des mesures répétées peuvent montrer si les chemins convergent vers le même opérateur. Les documents contractuels ou les schémas de réseau doivent identifier les interconnexions distinctes, les salles de rencontre et les entrées de bâtiment lorsque ces détails importent.

L’absence d’enregistrement PeeringDB public rend cette vérification plus difficile. PeeringDB aurait pu répertorier les échanges, les installations, la capacité et la politique, mais sa nature volontaire signifie que REG.RU peut simplement utiliser des accords privés ou choisir de ne pas publier. Les données RIPE confirment la joignabilité Internet et une adjacence variée; elles ne peuvent pas localiser chaque interconnexion. Le niveau de preuve correct est donc fort pour un réseau actif et de taille significative, et moyen à faible pour la diversité des routes par installation.

Cette distinction affecte également les conceptions « multi-sites » au sein d’un même fournisseur. Deux régions REG.RU peuvent utiliser des hôtes et un stockage distincts mais partager AS197695, les services d’atténuation, la gestion d’adresses ou la politique de transit externe. Cela peut être un compromis acceptable. Cela protège contre de nombreuses pannes locales tout en conservant une faible complexité opérationnelle. Cela n’équivaut pas à utiliser un fournisseur DNS indépendant, un second système autonome et un second cloud pour le chemin le plus critique.

La facturation, le support et le contrôle du compte sont des dépendances d’infrastructure

La panne d’infrastructure ne se limite pas au matériel cassé. Les conditions cloud de REG.RU décrivent un solde débité au fur et à mesure de l’utilisation des ressources, et le SLA exclut les interruptions liées au non-respect des conditions de paiement. Un service peut donc devenir indisponible en raison d’un état commercial même lorsque la baie, la route et l’hyperviseur sont sains. Les organisations doivent traiter les alertes de solde, les droits de renouvellement et les méthodes de paiement comme des contrôles de production.

Le compte a une importance similaire. Les services d’hébergement en Russie exigent l’identification du client, et leguide d’identification cloudde REG.RU applique cette exigence aux machines virtuelles, bases de données, Kubernetes, S3 et serveurs dédiés physiques. L’identification peut renforcer la responsabilité, mais elle introduit des dépendances de documentation et d’accès. Un client professionnel doit s’assurer que plus d’un employé autorisé peut gérer le compte et que les enregistrements de propriété restent à jour lorsque le personnel change.

La couverture du support est différenciée. REG.RU annonce un support technique 24 heures sur 24, tandis que songuide de support cloudinvite les clients à choisir une file d’attente spécifique au service et indique des horaires de consultation téléphonique quotidiens. Des avis de congés ont indiqué que le support technique pour les domaines, l’hébergement, les produits corporate et cloud se poursuit 24 heures sur 24, tandis que certaines fonctions de bureau ou de demande générale ferment. Cela rend l’acheminement des tickets et les droits d’escalade importants pendant un incident complexe.

Le support franchit également les frontières de responsabilité. Sur un serveur bare metal ou cloud non géré, le fournisseur peut rétablir l’alimentation, le réseau ou le matériel pendant que le client répare le système d’exploitation et l’application. Les services gérés transfèrent une partie de la responsabilité vers le haut, mais les clients restent propriétaires de la classification des données, du comportement de l’application et de la configuration des accès.

La page S3 divise explicitement les responsabilités: le fournisseur gère la réplication et l’infrastructure physique; le client gère les autorisations, le cycle de vie, le versionnage, les intégrations et les clés.

Un plan d’escalade pratique doit identifier le titulaire du contrat, les contacts techniques, les contacts de facturation et les preuves requises dans un ticket. Le SLA de REG.RU demande des informations détaillées sur le service et la panne et peut exiger l’accès à un serveur pour enquête. Pendant un incident, les retards pour trouver les identifiants ou l’autorisation peuvent allonger le temps d’arrêt même si le support est doté de personnel.

La concentration la plus dangereuse est un compte qui contrôle l’enregistrement de domaine, le DNS et l’infrastructure avec un seul identifiant et un seul chemin de paiement. Une conception plus sûre sépare les rôles, protège les actions à fort impact, conserve un enregistrement hors ligne des identifiants de ressources et dispose d’une seconde méthode de communication. C’est une hygiène opérationnelle ordinaire, mais l’étendue du catalogue de REG.RU la rend particulièrement lourde de conséquences.

La portabilité existe, mais la migration a un coût et une séquence

REG.RU fournit plusieurs interfaces ouvertes ou familières qui réduisent la dépendance. Les machines virtuelles peuvent exécuter des systèmes Linux et Windows courants. Les serveurs dédiés exposent IPMI ou KVM et autorisent les images de système d’exploitation du client. Le stockage objet utilise une interface compatible S3. Terraform est pris en charge pour certains provisionnements cloud. Les données peuvent être copiées avec des outils standard, et le DNS reste basé sur des enregistrements portables.

Leguide de migration cPanel-vers-ispmanagerdu fournisseur est précieux car il montre la séquence concrète: identifier les fichiers et les bases de données, créer une archive et un dump de base de données, noter la version du logiciel, créer l’environnement cible, charger les fichiers, les données, tester avant les modifications DNS, mettre à jour les enregistrements et déplacer le courrier séparément. Il s’agit d’une migration vers REG.RU, mais les mêmes composants doivent être compris pour une migration sortante.

La portabilité n’est donc pas une caractéristique binaire. Un petit site statique peut être copié rapidement. Une grande base de données nécessite une réplication ou une fenêtre de maintenance. Une base de données gérée peut exposer des outils de moteur standard tout en exigeant des versions et des extensions compatibles. Un magasin d’objets à l’échelle du téraoctet peut utiliser une API standard tout en prenant un temps considérable pour le transfert sur la connexion disponible. Les adresses IP publiques ne voyagent généralement pas vers un autre fournisseur, de sorte que le DNS, les certificats et les listes d’autorisation doivent changer.

La combinaison de services de REG.RU peut faciliter un déplacement par étapes. Un client peut construire un nouveau serveur, restaurer les données, le tester via une entrée de fichier hosts local ou un nom temporaire, et ne basculer l’enregistrement public que lorsqu’il est prêt. Le guide de migration recommande explicitement des tests avant le basculement. Cependant, utiliser le DNS de REG.RU à la fois pour l’ancien et le nouveau service signifie que le basculement dépend toujours de la même surface de contrôle.

Les migrations critiques peuvent justifier un arrangement DNS secondaire indépendant et une réduction anticipée des durées de vie des enregistrements.

Les sauvegardes doivent également pouvoir être exportées avant une urgence. Une sauvegarde hébergée par le fournisseur qui ne peut être restaurée que dans le même service est utile pour les erreurs locales, mais faible pour quitter le fournisseur. La compatibilité S3 et les copies de fichiers standard améliorent les options, à condition que les identifiants et la bande passante restent disponibles. Les clients doivent chronométrer un export représentatif et enregistrer les dépendances telles que les clés de chiffrement, les utilisateurs de bases de données, les certificats et les fichiers de licence.

L’économie de la sortie doit faire partie de l’architecture d’origine. Une capacité bon marché et rapidement disponible peut toujours coûter cher à quitter si le volume de données, les fonctionnalités gérées propriétaires ou les dépendances d’adresse s’accumulent. REG.RU offre suffisamment d’interfaces standard pour rendre la portabilité plausible. Les preuves publiques ne quantifient pas le débit d’exportation, les engagements de support pour le départ ou la durée pendant laquelle les données restent accessibles après la résiliation commerciale, de sorte que ces modalités doivent être confirmées directement.

La localisation des données est claire au niveau national et moins claire au sein des produits

REG.RU place systématiquement l’infrastructure annoncée en Russie. Le guide d’hébergement nomme des villes et adresses russes. Le catalogue cloud indique que ses installations Tier III se trouvent à Moscou, Saint-Pétersbourg et dans la région de Samara. La page S3 fait la même affirmation au niveau national. Pour les organisations tenues de conserver les données personnelles des citoyens russes en Russie, c’est une base pertinente.

Le fournisseur propose également des serveurs cloud conçus pour les exigences de la loi fédérale 152-FZ. Sadocumentation sur les serveurs réglementésidentifie un emplacement à Moscou et décrit la responsabilité du fournisseur pour l’infrastructure, une installation certifiée et des protections techniques. C’est plus spécifique qu’une promesse générique de « cloud local ». Cela ne transfère pas pour autant toute la responsabilité de conformité au fournisseur; le client reste l’opérateur de données personnelles et doit configurer et gouverner son système en conséquence.

La localisation a plusieurs niveaux. La localisation nationale demande si les données primaires restent en Russie. La localisation de l’installation demande dans quelle ville et quel bâtiment elles se trouvent. La localisation de la réplication demande où vont les copies et les sauvegardes. La localisation administrative demande qui peut y accéder. La localisation du support demande où le personnel et la gestion à distance opèrent. Les pages publiques répondent à la première question plus clairement qu’aux autres.

La géographie des produits peut également changer. La page marketing S3 fait référence à Moscou, Saint-Pétersbourg et Samara, tandis que des fonctionnalités cloud spécifiques peuvent n’être disponibles que dans une ou deux régions. L’annonce DBaaS décrit deux emplacements moscovites, et le lancement Blackwell est lié à Moscou-3. Un client ne peut pas déduire les options de placement d’un produit à partir de la carte corporate complète. L’interface de commande et le cahier des charges contractuel doivent identifier la région choisie.

La concentration nationale est à la fois un avantage et un risque. Elle répond aux exigences de résidence des données et de latence locale pour les utilisateurs russes. Elle signifie également que le parc annoncé est exposé à un seul environnement juridique, de marché de l’électricité et de connectivité national. Les clients servant des utilisateurs ailleurs doivent tester les routes internationales et examiner si une copie indépendante en dehors du fournisseur est légalement autorisée et opérationnellement souhaitable. La réponse dépend des données et des obligations du client, et non d’une étiquette de cloud générique.

À quoi ressemble une panne pour différents clients

Une petite entreprise utilisant REG.RU pour un domaine, un hébergement mutualisé et le courrier est la plus exposée aux pannes de compte, de DNS et de plateforme partagée. Les sauvegardes quotidiennes peuvent restaurer le site, mais les modifications faites après la dernière copie peuvent être perdues. Si le même compte contrôle le domaine et l’hébergement, un problème d’accès peut bloquer à la fois le diagnostic et la redirection. La meilleure amélioration est souvent modeste: une récupération de compte indépendante, une copie externe des données du site et du courrier, et une méthode documentée pour déplacer le DNS.

Une société de logiciels sur des machines virtuelles cloud est confrontée à des pannes de cluster, de stockage et de région. Les IP flottantes et les réseaux privés peuvent aider au sein d’un même emplacement. Les sauvegardes et les instantanés peuvent restaurer les instances. Ni l’un ni l’autre ne remplace un second emplacement en fonctionnement lorsque les objectifs de temps d’arrêt sont courts. L’entreprise a besoin d’une réplication au niveau applicatif, d’une surveillance externe et d’une capacité de réserve suffisante dans l’emplacement cible.

Un client sur bare metal assume davantage de responsabilité d’exploitation. IPMI peut restaurer l’accès console, et REG.RU peut remplacer le matériel défaillant, mais l’application peut rester liée aux disques locaux et à une machine spécifique. Les disques en miroir protègent contre certaines pannes de périphériques, non contre la perte du site ou la corruption. Un second serveur et une copie de données hors machine constituent les mesures de résilience minimales crédibles pour une charge de travail critique.

Un client ayant des données réglementées a une autre contrainte: la cible de récupération doit satisfaire aux mêmes exigences de résidence et de sécurité que la production. Une sauvegarde dans un emplacement non spécifié ou un cloud alternatif choisi à la hâte peut être inutilisable du point de vue de la conformité. Les multiples sites russes de REG.RU peuvent être utiles, mais le placement exact et les contrôles doivent être confirmés par écrit.

Les clients de domaines sont affectés même lorsqu’ils n’achètent pas d’hébergement. Le réseau actif AS197695 et les adresses DNS faisant autorité montrent que les services de nommage ont également des dépendances physiques et de routage. L’accréditation du registraire et le dépôt de données protègent certains aspects de la relation d’enregistrement, mais ils ne rendent pas l’architecture DNS choisie par le client continuellement disponible. L’enregistrement, le DNS faisant autorité et l’hébergement applicatif sont des fonctions distinctes et doivent être évaluées distinctement.

Dans chaque cas, le chemin de panne le plus important est une chaîne. Une perte d’alimentation peut mettre hors service une baie; une panne de route peut isoler une machine saine; une défaillance de stockage peut laisser le calcul fonctionner sans données; un problème de compte peut empêcher un basculement de trafic; un paiement expiré peut interrompre un service sain; et une escalade de support lente peut prolonger chacun de ces problèmes. Le client subit la dépendance non résolue la plus longue, pas le composant le plus solide du portefeuille.

Le verdict opérationnel: un réseau réel, une transparence partielle, une résilience construite par le client

REG.RU franchit le seuil d’un fournisseur d’infrastructure opérationnelle. La société registraire nommée est à jour dans le registre IANA, détient des ressources réseau RIPE et émet une large surface de routage active via AS197695. Le parc de services de marque contient un inventaire de bare metal commandable, des machines virtuelles, du stockage et des produits gérés. La documentation expose des adresses physiques, des méthodes de gestion à distance, un comportement de sauvegarde et un objectif de disponibilité contractuel. Ce sont des signaux opérationnels substantiels.

Les preuves sont moins complètes aux frontières. Les documents publics mélangent la marque du groupe et plusieurs sociétés juridiques. Les chiffres du portefeuille combinent des installations qui semblent avoir des propriétaires et des rôles différents. Les certifications d’installations et les mégawatts agrégés ne révèlent pas la capacité occupée ou disponible de REG.RU. La vue de routage mondiale ne prouve pas la diversité des circuits sur chaque site. Les pages produits ne fournissent pas une carte commune des domaines de réplication et de récupération.

Un historique structuré et public des incidents n’était pas disponible pour être comparé au SLA.

Cette combinaison ne mérite ni rejet ni confiance inconditionnelle. Les preuves réseau sont solides. Les preuves produit sont solides pour la disponibilité actuelle des services. Les preuves de propriété des installations et de redondance produit par produit sont moyennes à faibles. Les preuves historiques de pannes sont faibles. La bonne réponse du client est de recentrer chaque affirmation sur le service commandé.

Avant de placer une charge de travail critique, un acheteur doit obtenir des réponses écrites à un court ensemble de questions opérationnelles: la société contractante; l’installation sélectionnée et son opérateur; les domaines de panne de calcul, de stockage et de réseau; l’emplacement et l’immuabilité des sauvegardes; les engagements de point de récupération et de temps de récupération; le traitement des travaux planifiés; les conditions de remplacement matériel; l’escalade du support; les règles de solde et de suspension; et la route d’exportation testée.

Pour les conceptions multi-sites, l’acheteur doit également confirmer si la capacité est réservée sur l’emplacement alternatif et si le DNS, l’identité et la gestion restent utilisables lorsque l’emplacement principal tombe en panne.

La proposition de valeur de REG.RU est la réduction des frictions. Un client peut commencer avec un nom et ajouter des formes d’infrastructure de plus en plus physiques sans quitter l’environnement commercial unique. La réalité sous-jacente va en sens inverse: chaque service ajouté introduit des serveurs, des disques, des liaisons réseau, des contrats d’installation, des équipes de support et des décisions de récupération. L’interface cloud rend ces dépendances plus faciles à acheter. Elle ne les fait pas disparaître.