AP Serverhosh Internet Service vend de la capacité hébergée qui dépend encore de baies, de transit et de fenêtres de réparation

Résumé

• ServerHosh propose un vaste catalogue d'hébergement partagé, de VPS et de serveurs dédiés depuis une base commerciale en Inde, avec des emplacements annoncés à Seattle, Philadelphie, Phoenix et Londres. Les preuves réseau indépendantes les plus claires sont plus limitées: AS136175 originaire un préfixe IPv4 /24 via Wowrack et dispose d'une connexion de 1 Gbps au Seattle Internet Exchange.
• La société affirme être propriétaire du matériel et des équipements réseau, exploiter un transit direct et utiliser des suites privées dans les installations de Wowrack à Seattle et de Iron Mountain LON-1. Les registres publics confirment les installations et un certain espace d'adressage étiqueté ServerHosh, mais ne révèlent pas le nombre de baies, la puissance contractée, la capacité de basculement utilisable, l'inventaire des pièces de rechange ni la salle exacte de Londres.
• Une étiquette de port serveur de 1 Gbps ou 10 Gbps ne correspond pas à une capacité dédiée de bout en bout. Les conditions d'utilisation équitable de ServerHosh permettent de restreindre le port pour les charges de travail soutenues à large bande passante, tandis que la route globale actuelle de son propre ASN n'expose qu'un seul fournisseur amont observé et aucun espace IPv6 originaire.
• La récupération varie également selon le produit. L'hébergement partagé annonce des sauvegardes quotidiennes sur deux niveaux et une migration avec cPanel, tandis que les conditions générales considèrent les VPS et les serveurs dédiés comme non gérés et imposent de courts délais de suppression après impayé. Par conséquent, les clients ont besoin d'un plan de restauration, d'exportation et de continuité de facturation indépendant, au lieu de considérer un prix mensuel bas comme un produit de résilience complet.

Une façade cloud avec une chaîne d'approvisionnement physique

ServerHosh fait ressembler l'infrastructure à une liste de petites options mensuelles. Sapage d'accueil actuellepropose de l'hébergement partagé à partir de 1,99 $, des machines virtuelles aux États-Unis et au Royaume-Uni, et des serveurs dédiés en France, à Seattle et à Londres. Le catalogue va d'un compte d'hébergement web d'un gigaoctet à une machine dédiée avec 128 gigaoctets de mémoire. Un client peut sélectionner des cœurs, de la mémoire, du disque et une vitesse de port sans jamais voir une baie, un disjoncteur, un panneau de fibre optique ou la personne qui remplacera un disque défaillant.

Cette séparation est normale dans l'hébergement. C'est aussi là que réside le risque. ServerHosh ne se contente pas de vendre du temps CPU. Il assemble un service à partir de serveurs physiques, de logiciels de virtualisation, d'adresses IP, de liaisons montantes, d'un système de facturation et de main-d'œuvre de support. À Seattle et à Londres, il dépend également d'organisations qui contrôlent les bâtiments, les systèmes électriques, les installations de refroidissement, les comptoirs de sécurité et l'accès par intervention à distance. La capacité visible pour un acheteur n'est que la dernière portion d'une chaîne plus longue.

La société se décrit comme un fournisseur d'hébergement indien opérant depuis 2012. Sapage « à propos »cite Anirban Ghosh et Srabanti Paul comme propriétaires et énumère des fonctions opérationnelles et de support. Un registre corporatif indépendant indique que Serverhosh Internet Service Private Limited a étéconstituée au Bengale-Occidental en octobre 2020, avec Ghosh et Paul comme directeurs. Ces dates peuvent coexister: une marque commerciale ou une exploitation non constituée en société peut précéder une société à responsabilité limitée. Il ne faut pas les regrouper pour affirmer que l'entreprise actuelle possède les mêmes actifs, contrats ou structure opérationnelle depuis 2012.

Le bureau en contact avec la clientèle est également séparé des machines. Lapage de contactde ServerHosh indique une adresse à Calcutta et un numéro de téléphone indien. Elle annonce un support 24 heures sur 24, tandis que les ventes et la facturation sont indiquées du lundi au samedi. Il est promu que les machines se trouvent à des milliers de kilomètres. Il s'agit d'un accord de service distribué: gestion commerciale en Inde, capacité matérielle et réseau dans des installations étrangères, et demande client qui peut provenir de n'importe où.

Cet accord peut être économique. Un petit fournisseur n'a pas besoin de construire un centre de données pour louer une cage privée, acheter des serveurs dédiés, contracter du transit IP et placer des clients sur des machines virtuelles. Il peut combiner des frais généraux réduits avec un support direct et des options de produit limitées. Mais le même accord crée plusieurs limites qu'un acheteur doit tracer. Qui est le propriétaire du serveur? Qui détient le contrat des installations? Qui est autorisé à entrer dans la salle? Qui annonce l'espace d'adressage? Quelle partie remplace un disque à 03h00 heure locale?

Quel contrat régit un remboursement, une suspension, une fenêtre de maintenance ou une exportation de données?

Les documents publics de ServerHosh répondent à certaines de ces questions et en laissent d'autres ouvertes. La conclusion utile n'est pas que le service est imaginaire ni que toutes les affirmations doivent être acceptées. C'est que l'opération est visible à certains niveaux et opaque à d'autres. Le réseau a une trace publique actuelle. Le catalogue de produits est actif. Des installations tierces désignées existent.

Cependant, la quantité de capacité vendable, le chemin depuis un ticket jusqu'à un serveur réparé et la capacité de restaurer les données du client après une défaillance courante ne sont pas publiés de manière à ce qu'un client puisse les vérifier.

La preuve actuelle la plus solide est une route de Seattle

ServerHosh possède son propre système autonome, AS136175. Leregistre de l'APNICidentifie Serverhosh Internet Service, une adresse à Calcutta et Anirban Ghosh comme contact administratif et technique. Le registre attribue au système autonome un code pays des Pays-Bas, tandis que le registre d'organisation associé indique l'Inde. Les champs de pays dans les registres Internet sont des étiquettes administratives, pas une carte fiable de l'endroit où chaque serveur ou routeur est installé.

Le paysage de routage en direct est compact. Leprofil de AS136175de Hurricane Electric montrait un préfixe IPv4 originaire, 209.90.232.0/24, un voisin IPv4 observé, AS23033 de Wowrack, et aucun préfixe IPv6 originaire le 10 juillet 2026. Lamesure de l'état de routagede RIPE montrait indépendamment le même espace IPv4 de 256 adresses, sans espace IPv6 et un voisin observé. Sonhistorique des préfixes annoncésmontrait ce /24 visible en continu pendant la fenêtre de consultation de deux semaines précédente.

C'est une preuve opérationnelle positive. Une route actuelle n'apparaît pas simplement parce qu'un site web dit qu'un service existe. Elle nécessite une gestion des adresses, une politique de routeur et un fournisseur amont disposé à propager le préfixe. IPinfo rapporte également unespace d'adressage récemment répondu dans le /24, y compris une réponse mesurée depuis Seattle. Les observations appuient une empreinte réseau active à Seattle associée à ServerHosh.

Le Seattle Internet Exchange apporte une deuxième forme de preuve. Sontableau des entités actuelsrépertorie ServerHosh avec l'adresse IPv4 206.81.81.217 et l'adresse IPv6 2001:504:16::2:13ef, connecté à 1 Gbps sur le commutateur de Wowrack. L'entrée indique la connexion et l'adhésion avec droit de vote comme étant actuelles. Leregistre réseau de ServerHosh sur PeeringDBindique les mêmes adresses, une politique de peering ouverte et une portée mondiale.

L'entrée de l'échange doit être lue avec prudence. Elle ne montre pas que ServerHosh livre des routes vers les serveurs de route du SIX, et elle ne transforme pas un port d'échange de 1 Gbps en un deuxième fournisseur de transit. Le peering peut améliorer la portée vers les membres disposés, mais un port d'échange public et un amont Internet complet accomplissent des tâches différentes. Une charge de travail client a toujours besoin d'une route complète vers des réseaux qui ne font pas de peering avec ServerHosh. Le seul voisin observé au niveau mondial reste Wowrack.

Il y a aussi une grande différence d'échelle entre les observations actuelles et lapage réseaude ServerHosh. La société affirme que son service de Seattle dispose de 110 Gbit/s de capacité combinée actuelle, une connexion de transit de 100 Gbps avec Hurricane Electric, une connexion de 10 Gbps avec Wowrack, des commutateurs redondants et un accès au SIX. Ces chiffres peuvent décrire la connectivité de l'installation, la conception historique, la capacité disponible pour un fournisseur ou des liaisons inutilisées pour annoncer le seul préfixe visible de AS136175. Ils ne sont pas corroborés par la route publique pour cet ASN ni par l'entrée d'échange de 1 Gbps.

Cela ne prouve pas que les liaisons plus importantes sont absentes. Un fournisseur d'hébergement peut utiliser des adresses attribuées par le fournisseur et annoncées sous l'ASN d'un fournisseur, des VLAN privés, du transit protégé ou de la capacité que les collecteurs ne peuvent pas attribuer à son propre système autonome. Les preuves actuelles établissent moins: ServerHosh contrôle une route IPv4 visible via Wowrack et une connexion d'échange à Seattle.

Un inventaire des circuits actuels, un résumé de configuration du routeur et des graphiques de trafic séparés par emplacement seraient nécessaires pour valider la déclaration de capacité supérieure.

IPv6 illustre la même distinction. SIX et PeeringDB attribuent à ServerHosh une adresse d'échange IPv6, il existe donc une interface avec capacité IPv6 dans le tissu de l'échange. Cependant, l'entreprise n'originaire aucun préfixe IPv6 client dans la table globale. Une adresse LAN d'échange est une infrastructure pour le peering; ce n'est pas une attribution routable qu'un client VPS peut nécessairement utiliser.

Par conséquent, un acheteur nécessitant un service double pile devrait tester une machine virtuelle provisionnée et confirmer un préfixe IPv6, la route par défaut, le DNS inverse et le comportement de basculement, au lieu de se fier uniquement à l'enregistrement de l'échange.

L'installation de Seattle appartient au domaine opérationnel du propriétaire

ServerHosh dit avoir une suite privée avec Wowrack à Seattle. Lafiche technique de SEA1de Wowrack décrit une installation de 18 000 pieds carrés et 450 baies au 12201 Tukwila International Boulevard, avec 3 MW de capacité électrique, refroidissement N+1, systèmes d'onduleurs et de générateurs, intervention à distance, connectivité neutre vis-à-vis des opérateurs et accès au SIX sur le réseau. L'histoire de l'entrepriseWowrack indique qu'elle s'est étendue à une installation de 3 MW et 18 000 pieds carrés à Seattle en 2014.

La coïncidence entre ces chiffres et la propre description de ServerHosh est frappante. Les deux citent 18 000 pieds carrés, 3 MW, redondance de l'installation de refroidissement, haute densité de baies, accès au SIX et le même contexte opérationnel général de Seattle. Cela étaye l'interprétation selon laquelle ServerHosh décrit les capacités de l'installation de Wowrack dans laquelle il loue de l'espace, et non un bâtiment lui appartenant. C'est cohérent avec sa déclaration de colocalisation à Seattle et avec la relation BGP publique avec Wowrack.

La capacité de l'installation reste importante pour un locataire. Si les générateurs, les refroidisseurs ou les systèmes d'accès du site tombent en panne, les baies de ServerHosh sont affectées. Mais une spécification de l'ensemble du bâtiment ne peut pas être automatiquement reportée sur chaque produit client. Une installation de 3 MW ne dit rien sur le nombre de kilowatts contractés pour ServerHosh, la charge de ses bandes d'alimentation, si ses serveurs ont des alimentations doubles connectées à des chemins séparés ou combien de marge reste après une défaillance de composant.

L'adresse physique requiert également de l'attention. Un annuaire commercial associe ServerHosh à une adresse de Seattle d'apparence plus ancienne, tandis que les documents actuels de Wowrack situent SEA1 au 12201 Tukwila International Boulevard. La fiche technique actuelle de l'opérateur de l'installation est une preuve plus solide pour l'emplacement actuel. Néanmoins, elle n'identifie pas la cage, la suite, le nombre de baies ou la puissance de l'armoire de ServerHosh.

Un client cherchant une garantie physique devrait demander l'adresse de service actuelle dans la commande, l'opérateur de l'installation, le droit à la suite ou à la cage, la procédure d'accès et le point où commence la responsabilité de ServerHosh.

Lesrègles des installationsde Wowrack montrent pourquoi la limite a des conséquences opérationnelles. Les livraisons doivent être gérées via un ticket de support Wowrack, et l'opérateur peut prendre des mesures correctives lorsque des conditions dangereuses ou inacceptables ne sont pas corrigées. Il s'agit d'une gouvernance de colocation habituelle, mais cela signifie que le remplacement de matériel de ServerHosh peut dépendre des procédures du fournisseur, de l'acceptation de l'expédition et de la coordination des interventions à distance avant que son propre personnel ne puisse terminer la réparation.

Par conséquent, la limite de propriété comporte au moins quatre niveaux. Wowrack ou le propriétaire de l'immeuble gère l'installation du site et le régime d'accès. Wowrack fournit le transit réseau visible en BGP. ServerHosh déclare être propriétaire du matériel et des équipements réseau dans son espace. Le client contrôle le système d'exploitation et l'application pour les produits non gérés. Un plan de récupération qui ne nomme que ServerHosh omet les parties qui contrôlent la salle, la route et la charge de travail.

Londres est visible, mais la salle exacte ne l'est pas

L'histoire britannique de ServerHosh est plus complexe. La société dit que sa suite privée est chez Iron Mountain LON-1. Leprofil officiel de LON-1d'Iron Mountain décrit une grande installation à Slough avec six salles de données, 17 000 mètres carrés et 8,7 MW de puissance, en plus d'armoires individuelles, de cages, de suites privées et d'interventions intelligentes 24 h/24. Unedescription générale des emplacementsséparée d'Iron Mountain énumère LON-1 au 724-729 Dundee Road, avec des refroidisseurs N+1, des générateurs et des systèmes d'onduleurs.

Ces registres établissent LON-1 et ses vastes capacités d'installation. Ils n'établissent pas quelle salle, baie ou chemin d'alimentation occupe ServerHosh. ServerHosh ne figure dans aucun service d'interconnexion londonien dans son enregistrement PeeringDB, et AS136175 n'expose pas de route londonienne. Aucun de ces faits ne réfute l'existence d'une suite privée. Les déploiements privés de clients n'apparaissent souvent pas dans les bases de données publiques d'installations, et un fournisseur peut utiliser un espace d'adressage annoncé par un autre réseau.

Il y a un signal plus spécifique pour Londres. Le nom d'hôte que ServerHosh publie pour son looking glass londonien se résout en 41.216.187.0/24. Leprofil de registre et de routage de ce préfixel'étiquette comme ServerHosh Internet Service et le place sous l'ASN client de PebbleHost AS201002 au Royaume-Uni. BGP.tools montre également le/24 étiqueté comme ServerHosh sous PebbleHost. Cela étaye une relation actuelle d'espace d'adressage britannique, mais ne lie pas la route à Iron Mountain LON-1.

La distinction est importante car l'emplacement du centre de données et l'origine du réseau sont des faits différents. Un serveur de ServerHosh pourrait être à LON-1 tandis que son trafic est acheminé par PebbleHost. Il pourrait également être hébergé dans une autre installation britannique utilisant le même préfixe. Le nom d'hôte DNS, l'enregistrement du préfixe et les observations de faible latence à Londres établissent une présence réseau britannique à un niveau utile, mais un acheteur exigeant une résidence à Slough a besoin d'une confirmation contractuelle du site physique et de la liste des sous-traitants.

Lapage des serveurs dédiés au Royaume-Unide ServerHosh nomme explicitement Iron Mountain LON-1 et annonce des systèmes Ryzen avec des connexions de 1 Gbps non mesurées. Cependant, lecatalogue de commandeslié montrait zéro unité disponible pour chaque configuration de serveur dédié britannique affichée au moment de la consultation. Un stock à zéro ne prouve pas que l'emplacement est inactif. Cela montre plutôt pourquoi la conception du catalogue et la capacité installée doivent être séparées. Une page peut continuer à annoncer un produit dont l'inventaire immédiatement provisionnable est épuisé ou en attente d'un assemblage personnalisé.

Le catalogue VPS de Londres fait une promesse plus large. ServerHosh annonce desmachines virtuelles de 10 Gbpsavec bande passante non mesurée, protection DDoS et une disponibilité réseau de 99,99 %. La page indique que l'hôte physique dispose d'un port full-duplex redondant de 10 Gbps et que ServerHosh possède son matériel et ses équipements réseau. Elle ne précise pas combien d'instances VPS partagent cet hôte, si les deux ports redondants aboutissent à des commutateurs indépendants, le seuil d'utilisation équitable ou le débit mesuré disponible lors d'une attaque ou d'une défaillance de l'amont.

Ce n'est pas une objection sémantique. Un client qui achète une machine virtuelle ne peut pas consommer plus de capacité physique que ce que peuvent offrir l'hôte, le commutateur et la liaison montante. Si vingt invités partagent un port hôte de 10 Gbps, leurs interfaces annoncées peuvent toutes être de 10 Gbps alors que le débit simultané utilisable est bien moindre. Si un deuxième port est de secours dans la même pile de commutateurs, il protège un câble ou une interface, mais pas le commutateur, l'opérateur de transit ou l'installation.

Le chiffre manquant n'est pas la vitesse du port; c'est la capacité de service engagée et testée en situation de contention et de panne.

La capacité installée n'est pas la même que la capacité en vente

Les pages produits de ServerHosh révèlent un large mélange de générations de matériel et d'hypothèses commerciales. Lapage d'hébergement mutualisé NVMeannonce des formules sur une plateforme Intel E3-1270v6, de un à 70 gigaoctets de stockage, avec cPanel, CloudLinux, LiteSpeed et une connexion serveur de 1 Gbps. Lapage VPS de stockageindique que chaque serveur physique dispose de quatre disques SATA de 4 To en RAID 10 et vend des allocations virtuelles de 500 Go à 4 To. La page des serveurs dédiés aux États-Unis répertorie des machines Xeon E3 et double Xeon plus anciennes à Seattle, ainsi que des options Ryzen et Xeon plus récentes à Philadelphie et du stock prévu à Phoenix.

Il n'y a rien de fondamentalement mauvais avec le matériel plus ancien. Un serveur déjà amorti peut rendre viable une offre d'hébergement à bas coût, et les plateformes matures peuvent être stables si elles sont entretenues. L'ancienneté modifie l'équation opérationnelle. Les cartes mères de rechange, la mémoire compatible, les contrôleurs RAID et les disques d'entreprise peuvent être plus difficiles à obtenir rapidement. La consommation d'énergie par unité de travail est généralement plus élevée. Le support du micrologiciel peut être limité.

La bonne question n'est pas de savoir si toutes les machines sont neuves, mais si le fournisseur dispose de pièces de rechange testées et peut restaurer la charge de travail dans un délai déterminé.

Lecatalogue de serveurs dédiés américainsexpose cet effet d'inventaire. Certains systèmes de Seattle apparaissent en rupture de stock tandis que d'autres restent commandables; les configurations de Phoenix sont marquées « à venir ». La page indique que la plupart des serveurs sont configurés sur mesure et donne un délai de livraison habituel de 48 heures, pouvant aller jusqu'à trois jours ouvrables. Ce délai est la preuve qu'une fiche produit n'est pas nécessairement une machine installée, alimentée et prête. Le provisionnement peut nécessiter un assemblage, des tests, une allocation ou un transfert du fournisseur.

La capacité virtuelle ajoute une autre couche. Un plan VPS alloue des cœurs et de la mémoire virtuels, mais les pages publiques n'indiquent pas le nombre d'invités par hôte, la politique de contention CPU, la surallocation de mémoire, l'objectif de latence de stockage ou la proportion d'hôtes de réserve. Un fournisseur peut vendre plus de cœurs virtuels nominaux que de cœurs physiques parce que les clients atteignent rarement leur pic en même temps. C'est le moteur économique de l'hébergement VPS abordable.

Cela devient un problème de défaillance lorsque trop d'invités ont besoin de capacité en même temps ou lorsqu'un hôte tombe en panne et que les hôtes restants manquent de place pour les absorber.

Le stockage a une arithmétique similaire. Quatre disques de 4 To en RAID 10 fournissent environ la moitié de la capacité brute avant le formatage et l'espace de réserve, pas 16 To de stockage protégé vendable. Si un fournisseur alloue plusieurs disques virtuels de 4 To, il peut dépendre du provisionnement fin ou du fait que les clients n'utilisent pas toutes leurs allocations en même temps. La page ne révèle pas la méthode de provisionnement. Le RAID 10 peut tolérer certaines défaillances de disque, mais la reconstruction consomme des E/S et une deuxième défaillance sur le mauvais miroir peut toujours faire perdre la grappe.

La capacité réservée pour les reconstructions et les migrations fait partie de la capacité de service utilisable même si elle ne génère pas de facturation.

Les étiquettes de bande passante sont particulièrement faciles à surinterpréter. ServerHosh utilise à plusieurs reprises « non mesuré » à côté de ports de 1 Gbps et 10 Gbps. Sesconditions généralesdéfinissent le service non mesuré comme soumis à une utilisation équitable, interdisent plusieurs applications continues à large bande passante et permettent de restreindre la vitesse du port lorsque l'utilisation sort du modèle établi. Cela fait de « non mesuré » une description de facturation, et non une garantie de transfert soutenu à la vitesse de la ligne.

Par conséquent, un client devrait s'interroger sur quatre chiffres de capacité distincts: la vitesse de l'interface présentée au serveur; toute limite de transfert mensuel ou seuil d'utilisation équitable; la vitesse engagée en situation de contention ordinaire; et la vitesse minimale attendue après une défaillance de liaison, de commutateur ou d'hôte. Seul le premier est mis en avant dans le catalogue. Sans les trois autres, une étiquette de 10 Gbps décrit une condition d'interface locale maximale, non le débit disponible pour restaurer des téraoctets de données pendant un incident.

L'alimentation et le refroidissement restent des promesses héritées

Les deux opérateurs d'installations nommés publient des descriptions d'ingénierie crédibles. Wowrack indique que SEA1 à Seattle dispose de 3 MW de puissance, de configurations d'onduleurs 2N ou N+1, de secours par générateur, de refroidissement N+1 et de support haute densité. Iron Mountain décrit une installation N+1 à LON-1. Ce sont des attributs de site significatifs. Les baies de ServerHosh dépendent encore de la façon dont son propre équipement est connecté à l'intérieur de ces sites.

Un serveur avec un double câblage peut recevoir deux chemins d'alimentation. Un serveur bas de gamme avec un seul câble connecté à une bande d'alimentation de baie ne le peut pas. Deux bandes de baie peuvent toujours partager un panneau amont. Une suite peut être limitée à une enveloppe de kilowatts contractée même si le bâtiment a des mégawatts de capacité installée. Une fois qu'un locataire atteint cette enveloppe, il peut avoir des unités de baie vides mais sans puissance disponible pour un autre serveur.

ServerHosh ne publie pas sa puissance contractée, la charge actuelle des baies, le plan des chemins d'alimentation ni le pourcentage d'équipements à double câblage. Il n'indique pas non plus si ses commutateurs réseau, son stockage et sa gestion hors bande suivent le même modèle de redondance. Une installation peut respecter sa propre conception tandis qu'un locataire crée un point de défaillance unique à l'intérieur de la cage.

Le refroidissement suit la charge. L'opérateur du bâtiment peut maintenir des refroidisseurs N+1, mais le locataire contrôle les panneaux obturateurs, le flux d'air, l'obstruction des câbles, la densité de la baie et la rapidité avec laquelle de nouveaux équipements sont ajoutés. Une baie à haute densité peut développer un point chaud local tandis que la salle reste dans sa moyenne cible. Une garantie utile pour le client indiquerait la température d'entrée dans la baie, les seuils d'alarme, la responsabilité de la réponse et le temps nécessaire pour réduire la charge ou déplacer les invités après une perte de refroidissement.

L'énergie reste la cause la plus fréquente de pannes graves et sévères dans les centres de données selon l'analyse des pannes 2025d'Uptime Intelligence. Le rapport avertit également que les données sur les pannes sont incomplètes et que les défaillances dans les procédures du personnel comptent. C'est le bon niveau d'inférence ici. Il ne montre pas que ServerHosh ou l'une des installations a subi un événement énergétique particulier. Il montre pourquoi un pourcentage de disponibilité non qualifié est plus faible qu'un chemin testé à travers la perte du réseau public, le démarrage du générateur, le fonctionnement de l'onduleur, la distribution en baie et le redémarrage du serveur.

La maintenance crée un test plus ordinaire que le désastre. Les générateurs nécessitent des tests de charge. Les modules d'onduleurs nécessitent un entretien. Les commutateurs nécessitent des changements de logiciel. Les disques nécessitent un remplacement. Un fournisseur résilient devrait pouvoir isoler un composant sans arrêter la charge de travail hébergée, ou expliquer l'interruption planifiée s'il ne le peut pas. ServerHosh ne publie pas de calendrier de maintenance, de période de préavis, d'exclusion de maintenance dans sa déclaration de disponibilité ni d'historique des tests de basculement effectués.

L'impact sur le client varie selon le produit. Un utilisateur d'hébergement mutualisé peut perdre un site web, des e-mails et une base de données en même temps parce qu'ils partagent un même serveur. Un utilisateur de VPS peut conserver un disque virtuel intact mais perdre l'accès lorsque l'hôte ou l'amont tombe en panne. Un utilisateur de serveur dédié peut n'avoir aucune machine alternative. L'installation redondante du site réduit le risque commun, mais seule la réplication d'applications dans un domaine de défaillance véritablement séparé peut protéger contre la perte de la baie, de la suite, du compte fournisseur ou du site.

La diversité de transit est plus réduite que la liste des emplacements

ServerHosh commercialise plusieurs villes, ce qui peut sonner comme de la diversité réseau. Une liste d'emplacements n'est pas une conception de basculement. Les produits de Seattle, Philadelphie, Phoenix et Londres peuvent être commandés séparément, utiliser différents fournisseurs et ne pas avoir de relation automatique entre eux. Un client avec un VPS dans une ville a un emplacement de charge de travail, quel que soit le nombre d'autres villes qui apparaissent au menu.

Pour le propre ASN de ServerHosh, la route Internet visible est d'origine unique via Wowrack. La connexion SIX fournit une connexion d'échange séparée, mais elle ne semble pas originaire le seul préfixe client de l'entreprise via les serveurs de route de l'échange. Si la session de transit de Wowrack, le transfert interne ou le routeur de ServerHosh tombe en panne, le /24 peut être retiré même si le bâtiment et les serveurs restent alimentés.

La page réseau de l'entreprise désigne Hurricane Electric comme fournisseur principal de transit de 100 Gbps, mais les collecteurs publics ne montraient pas AS6939 adjacent à AS136175 le 10 juillet 2026. Plusieurs explications sont possibles: la liaison peut desservir des adresses attribuées par le fournisseur, être derrière Wowrack, être inactive ou être une capacité d'installation décrite comme capacité du locataire. Le registre public ne peut pas trancher entre elles. Un résumé BGP actuel montrant les sessions amont établies et les préfixes que chacune reçoit résoudrait la question.

Il y a aussi un décalage d'échelle entre un port SIX visible de 1 Gbps et les pages produits qui proposent plusieurs serveurs de 1 Gbps ou 10 Gbps. Le port d'échange n'est pas la seule capacité réseau de l'installation, de sorte que le catalogue n'est pas mathématiquement impossible. Cela signifie que l'échange ne peut pas transporter la vitesse d'interface annoncée complète de chaque client simultanément. Il en va de même pour toute connexion d'hôte de 10 Gbps partagée entre des machines virtuelles.

La protection DDoS introduit une autre dépendance. Les pages produits annoncent un service protégé, et le catalogue de commandes de Londres fait référence à un chiffre de protection standard de 600 Gbps sur certains systèmes. Ce chiffre peut décrire la capacité agrégée d'une plateforme de mitigation plutôt que le trafic livrable à un seul serveur. La protection effective dépend également de la détection, de la politique de nettoyage, de la capacité du chemin propre, du type d'attaque, des seuils de routage nul et de la communication avec le client. Rien de tout cela n'est défini publiquement.

Le test pratique de redondance comporte trois parties. Premièrement, le préfixe peut-il rester accessible globalement après la désactivation d'une session amont? Deuxièmement, le client peut-il recevoir suffisamment de trafic propre après la mitigation pour que l'application reste utile? Troisièmement, l'accès au DNS, au panneau de contrôle et aux systèmes de tickets peut-il être maintenu pendant la même panne? Réussir seulement la première laisse le service opérationnel en théorie mais inutilisable pour le client.

La défaillance matérielle devient un problème de stock et d'accès

Les serveurs physiques tombent en panne de manières spécifiques. Les disques accumulent des erreurs. Les ventilateurs se grippent. Les alimentations disjonctent. La mémoire développe des défauts. Les cartes mères et les contrôleurs RAID cessent de répondre. Le temps de récupération dépend moins de l'expression « matériel fiable » que de savoir si la pièce de rechange exacte est à proximité, testée et accessible.

ServerHosh déclare être propriétaire de son matériel et de ses équipements réseau. Cela peut être un avantage car l'entreprise n'attend pas qu'un fournisseur cloud exposé une option de remplacement. La propriété fait également peser le risque d'inventaire sur un fournisseur relativement petit. Le catalogue public ne montre pas les décomptes de pièces de rechange, les hôtes de réserve, la résilience des disques, la couverture de garantie ou la répartition par âge de l'équipement installé.

À Seattle, une réparation peut nécessiter que ServerHosh diagnostique la panne à distance, ouvre la demande appropriée auprès de Wowrack, identifie l'armoire, autorise le travail et fournisse ou expédie la pièce. Wowrack annonce une intervention à distance 24 h/24, mais la portée, le temps de réponse et le coût dans le contrat de ServerHosh ne sont pas publics. À Londres, Iron Mountain annonce un objectif d'accusé de réception de la plupart des demandes d'intervention intelligente en 30 minutes. L'accusé de réception n'est pas la restauration; le technicien a toujours besoin d'une méthode approuvée et d'un composant de rechange.

Les serveurs dédiés configurés sur mesure rendent visible le problème d'inventaire avant une panne. ServerHosh donne un délai de livraison de un à trois jours ouvrables et marque plusieurs configurations comme indisponibles. Le remplacement pendant une panne peut ne pas suivre la fenêtre de livraison commerciale, en particulier pour une plateforme Xeon plus ancienne ou une conception de disque spécifique au client. Un engagement utile spécifierait l'objectif de réparation par composant, les pièces conservées sur site et l'alternative si une pièce de rechange exacte ne peut être trouvée.

La récupération de VPS peut être plus rapide si le fournisseur dispose de stockage partagé ou d'images répliquées pouvant démarrer sur un autre hôte. ServerHosh ne décrit pas une telle architecture de cluster. La virtualisation KVM, annoncée sur plusieurs pages, isole les invités et peut prendre en charge la migration, mais KVM seul ne réplique pas un disque ni ne réserve de capacité de destination. Si le disque virtuel n'existe que sur des disques à l'intérieur de l'hôte défaillant, un autre hyperviseur ne peut pas le récupérer tant que le stockage n'est pas réparé ou restauré.

La fenêtre de réparation interagit également avec la sécurité. Un remplacement précipité nécessite un micrologiciel correct, une désinfection des disques, un isolement du client et un contrôle de configuration. Une pièce de rechange qui n'a jamais été testée peut allonger l'incident. Un disque défaillant retiré du système d'un client contient toujours des données. Les conditions publiques ne spécifient pas la conservation des supports, la destruction ou les options du client pour les disques défaillants.

Les clients peuvent réduire ce risque en traitant un serveur virtuel ou dédié comme remplaçable. Conservez la configuration de la machine hors de l'hôte, automatisez les reconstructions, gardez des images logicielles à jour et testez la restauration de l'application chez un autre fournisseur ou emplacement. Cela déplace la récupération de l'attente d'une carte mère spécifique au lancement d'une capacité valide connue ailleurs.

Les affirmations sur les sauvegardes se divisent radicalement par produit

La page d'accueil de ServerHosh indique qu'elle effectue des sauvegardes quotidiennes pour l'hébergement. La page d'hébergement mutualisé NVMe est plus spécifique, indiquant une sauvegarde quotidienne sur deux niveaux et un stockage RAID 1. Ces promesses semblent s'appliquer à l'hébergement mutualisé. Les conditions générales indiquent que tous les VPS et serveurs dédiés ne sont pas gérés et ne reçoivent qu'un support de base. Elles ne promettent pas de sauvegardes gérées par le fournisseur pour ces produits.

Cette distinction est facile à négliger car « sauvegarde gratuite » apparaît à côté de certaines promotions VPS. Un acheteur doit savoir si la sauvegarde signifie un instantané de l'hôte, une copie dans la même baie, une copie dans une autre installation ou un service que le client doit configurer. Il a également besoin de la durée de conservation, de la fréquence, du chiffrement, du coût de restauration et de la date du dernier test de restauration réussi. Aucun de ces détails n'est publié pour l'ensemble des produits.

Le RAID ne remplace pas la sauvegarde. La redondance en miroir ou par bandes peut maintenir un volume en fonctionnement après la défaillance d'un disque, mais elle reproduit également la suppression accidentelle, la corruption et les ransomwares. Si tout le serveur, le contrôleur ou la baie est perdu, la grappe est perdue avec eux. Un instantané de l'hôte peut échouer pour la même raison s'il réside sur le même ensemble de stockage.

Leguide sur les ransomwaresde la CISA recommande des sauvegardes hors ligne, chiffrées, et des tests périodiques d'intégrité et de restauration. Leguide de planification de la continuitédu NIST traite également du stockage alternatif, du traitement alternatif, des télécommunications et des sauvegardes comme des parties liées de la récupération. Ce sont des points de référence généraux, pas des preuves que ServerHosh les suit ou non.

Pour ServerHosh, la preuve décisive serait un calendrier de sauvegarde spécifique par produit et un résultat de restauration. Un rapport d'hébergement mutualisé pourrait indiquer quand chaque niveau a été achevé, où réside la deuxième copie et combien de temps a pris une restauration complète du compte. Une option VPS pourrait définir des instantanés séparément des sauvegardes indépendantes. Un client de serveur dédié devrait supposer qu'il n'y a pas de copie fournisseur à moins que la commande ne l'ajoute expressément.

Lapage publique de disponibiliténe couvre pas cette lacune. Elle présente un calendrier de sept jours et un calculateur de plage de dates, mais n'expose pas de services nommés, d'historique des incidents, de ventilation par emplacement ni de métriques de restauration dans la vue accessible. Un moniteur de disponibilité peut montrer qu'un point de terminaison a répondu; il ne peut pas montrer si les sauvegardes sont à jour ou si un serveur corrompu peut être reconstruit.

Les avis clients ne fournissent que des signaux faibles. Leprofil Trustpilotrevendiqué par ServerHosh contient des récits positifs de service stable et d'aide rapide, ainsi que des plaintes concernant des temps d'arrêt, la communication du support et des pertes de données. Il y avait 64 avis et aucun au cours des 12 derniers mois au moment de la vérification. Les avis sont autosélectionnés, portent sur différents produits et périodes, et ne peuvent pas établir un taux de défaillance actuel. Ils identifient en revanche les questions que les acheteurs devraient vérifier: le temps de réponse, l'interprétation de la bande passante et la responsabilité de la restauration.

La facturation peut arrêter un serveur sain plus vite que le matériel

Toutes les interruptions ne commencent pas dans une salle de données. Les conditions de ServerHosh indiquent qu'un serveur dédié peut être annulé définitivement 24 heures après une facture impayée, un VPS supprimé après 72 heures et l'hébergement mutualisé ou revendeur annulé après cinq jours. Ces délais sont courts par rapport à de nombreux processus de récupération d'entreprise. Une carte de paiement expirée, un e-mail perdu ou une facture contestée peuvent se transformer en un événement de perte de données alors que la machine physique reste en bon état.

Le risque est amplifié par la division des horaires de support. Le support technique est annoncé en continu, mais la facturation est indiquée du lundi au samedi. Une suspension en fin de semaine peut nécessiter une autorisation commerciale qu'un responsable technique n'a pas. Les documents publics n'indiquent pas de voie d'escalade pour une erreur de facturation menaçant une suppression imminente.

Le langage sur les remboursements est incohérent entre les pages. Lapolitique générale de remboursementaccorde à l'hébergement mutualisé mensuel une garantie de 15 jours, exclut les serveurs dédiés, restreint plusieurs autres cas et indique que les politiques peuvent changer. La page NVMe décrit un remboursement de 15 jours suivi d'un éventuel remboursement partiel. La page VPS de Londres propose un remboursement complet sous 48 heures et un remboursement partiel ensuite. La page des serveurs dédiés au Royaume-Uni indique qu'un remboursement est disponible si la livraison n'a pas lieu sous 48 heures. Un acheteur ne peut pas combiner en toute sécurité la phrase la plus favorable de chaque page.

Les conditions commerciales applicables doivent être jointes à la commande spécifique. Elles doivent indiquer la livraison, l'annulation, l'avoir de service, le préavis de suspension, le moment de la suppression et la gestion des paiements contestés. Pour une charge de travail importante, le client devrait également maintenir plus d'un contact de facturation autorisé, surveiller la livraison des factures en dehors du domaine hébergé et éviter de stocker l'unique copie du courriel de facturation sur le service qui pourrait être suspendu.

Il s'agit d'une question d'économie de l'hébergement, pas de simple administration. Les prix bas reposent sur la standardisation, l'automatisation et un contrôle strict des abus et des impayés. ServerHosh examine manuellement les commandes, limite les utilisations à large bande passante et peut annuler les activités interdites. Ces politiques protègent la réputation IP limitée, le temps de support et la capacité de transit. Elles créent également la nécessité d'une détection précise et d'un processus d'escalade équitable, car une décision incorrecte d'abus ou de facturation peut supprimer le seul serveur d'un client.

L'entreprise dispose d'adresses distinctes pour le support, les ventes, la facturation et les abus, ce qui est mieux qu'une boîte générique unique. Elle ne publie pas de niveaux de gravité, d'objectifs de réponse, de rôles d'incident désignés, d'escalade téléphonique pour les clients existants ni de pratique de rapports post-incident. Par conséquent, la disponibilité 24 h/24 décrit le canal, pas un temps garanti jusqu'au diagnostic ou à la réparation.

La migration est possible, mais la portabilité est conditionnelle

ServerHosh annonce des remises pour les clients qui transfèrent depuis un autre fournisseur. Sa page d'hébergement NVMe indique que la migration gratuite n'est disponible que lorsque l'hôte précédent utilise cPanel. C'est une limite concrète et sensée: cPanel peut empaqueter des comptes, des bases de données, des boîtes aux lettres et des configurations dans un format qu'un autre serveur cPanel peut restaurer. Cela signifie aussi que l'offre de migration n'est pas universelle.

Un site WordPress peut souvent être transféré avec des fichiers et une base de données. Un VPS peut contenir des utilisateurs système, des règles de pare-feu, des logiciels sous licence, des tâches planifiées, des réseaux privés et un grand disque. Un serveur dédié peut utiliser une conception RAID ou un système d'exploitation qui ne peut pas être copié directement sur un matériel différent. Les pages publiques de ServerHosh ne définissent pas comment ces charges de travail sont exportées ni si le personnel aidera après le transfert initial.

Les adresses IP sont une autre limite de portabilité. Un client ne peut généralement pas emporter une adresse attribuée par le fournisseur vers un nouvel hôte. Transférer depuis l'espace de Seattle de ServerHosh ou une plage londonienne annoncée par un fournisseur peut nécessiter une renumérotation, des changements DNS, un nouveau DNS inverse et des mises à jour des listes d'autorisation. La réputation de messagerie liée à une adresse n'est pas transférée automatiquement. Par conséquent, un transfert effectué pendant une panne peut prendre plus de temps que la copie des données.

Les panneaux de contrôle réduisent l'administration courante mais peuvent créer des dépendances propres. ServerHosh utilise cPanel pour l'hébergement mutualisé et annonce des panneaux de machine virtuelle pour l'installation du système d'exploitation, le redémarrage et l'accès à la console. Un client devrait exporter les données dans des formats ordinaires et conserver les identifiants en dehors du compte du fournisseur. Le portail de gestion, le système de facturation et la machine hébergée ne devraient pas former un seul domaine de défaillance d'authentification.

Le NIST décrit la planification de la continuité comme une combinaison de mesures techniques, de procédures et d'emplacements de traitement alternatifs, pas simplement un fichier de sauvegarde. Pour un client de ServerHosh, un test de portabilité réaliste consisterait à provisionner une machine propre ailleurs, à restaurer l'application, à effectuer une rotation des secrets, à changer le DNS et à mesurer le temps jusqu'à ce que les utilisateurs puissent se connecter. Le test devrait inclure les données créées après la dernière sauvegarde et les dépendances telles que la messagerie, les certificats et les rappels de paiement.

La récupération multisite ne s'obtient pas en commandant deux emplacements ServerHosh, à moins de cartographier leurs dépendances. Seattle dépend clairement de Wowrack pour la route observée. L'espace d'adressage londonien visible via le nom d'hôte publié dépend du routage de PebbleHost. Cela représente une diversité de fournisseurs prometteuse, mais le client doit encore confirmer que les comptes, les plans de contrôle, les sauvegardes et la facturation ne sont pas partagés de manière à ce qu'un seul incident commercial ou de sécurité désactive les deux.

La meilleure position de sortie est celle qui fonctionne sans intervention du fournisseur. Cela signifie des copies de données à jour, des enregistrements de configuration, le contrôle du domaine, une supervision indépendante, une destination testée et une bande passante suffisante pour migrer dans le temps de récupération requis. Une offre de migration gratuite peut réduire le coût d'entrée; seule une exportation testée réduit le coût de sortie.

La localisation des données nécessite un contrat, pas une étiquette de ville

La zone de service de ServerHosh est mondiale, mais sa géographie opérationnelle comporte plusieurs niveaux. La gestion de l'entreprise et du client est en Inde. Les pages produits publiques placent des machines aux États-Unis et au Royaume-Uni, avec des offres supplémentaires mentionnant la France et les Pays-Bas. Les registres réseau montrent un /24 originaire de ServerHosh à Seattle et un /24 étiqueté ServerHosh routé via un fournisseur britannique. Les données d'un client peuvent également transiter par des services de paiement, de support, de supervision et de panneau de contrôle en dehors de la ville du serveur.

Lapolitique de confidentialitéde l'entreprise indique qu'elle traite les noms, les données de contact, les adresses IP, les informations commerciales, les données de paiement et les communications, et que les données de la relation client peuvent être stockées dans WHMCS. Elle décrit la sécurité et la conservation en termes généraux. Elle n'identifie pas les sous-traitants de l'hébergement, les pays de traitement, un calendrier fixe de suppression, les mécanismes de transfert international ni l'installation utilisée pour chaque produit.

Cela est indépendant du contenu d'un serveur non géré. Un fournisseur d'hébergement peut agir dans différents rôles pour les enregistrements de facturation, les tickets de support et les données personnelles hébergées par le client. Le Bureau du commissaire à l'information du Royaume-Uni explique dans songuide sur les responsables de traitement et les sous-traitantsque les rôles dépendent de qui détermine les finalités et les moyens du traitement, et que le sous-traitant ultérieur change les responsabilités. Songuide sur les transferts internationauxaborde spécifiquement le cas d'un sous-traitant qui transfère des informations à un sous-traitant ultérieur à l'étranger.

Le cadre de protection des données de l'Inde est également allé au-delà d'une déclaration de confidentialité générique. Le ministère de l'Électronique et des Technologies de l'information a publié lesRègles de protection des données personnelles numériques de 2025, avec un calendrier de mise en œuvre. Les obligations légales pour un client particulier dépendent des données, des parties et des dispositions en vigueur. La leçon d'infrastructure est plus simple: un acheteur ne peut pas évaluer la localité uniquement par la ville dans le titre d'un produit.

Un client ayant des exigences de résidence ou de souveraineté devrait demander à ServerHosh le pays physique exact, l'opérateur de l'installation, les sous-traitants, les emplacements de sauvegarde, les pays d'accès au support, les emplacements d'enregistrement et le processus de suppression. Il devrait également demander si la plage IP attribuée est portable dans le même pays en cas de changement du fournisseur sous-jacent. La réponse devrait faire partie de la commande de service et du processus de notification des changements.

Les preuves londoniennes montrent pourquoi. Une page peut nommer Iron Mountain LON-1 tandis qu'un préfixe étiqueté ServerHosh et un hôte de looking glass sont routés via PebbleHost. Ces faits ne sont pas contradictoires, mais ils décrivent différentes surfaces de contrôle. L'emplacement de l'installation répond à la question de savoir où se trouve un serveur. L'origine de la route répond à qui transporte son espace d'adressage. L'emplacement du support répond à qui peut y accéder. L'emplacement de la sauvegarde répond à où existe une autre copie. La souveraineté des données exige les quatre.

Six défaillances révèlent le service réel

La première défaillance est une interruption de la baie ou de l'installation. Si le chemin d'alimentation contracté, la zone de refroidissement ou l'armoire de ServerHosh tombe en panne, la redondance sous-jacente du bâtiment peut limiter l'incident, mais seuls les équipements à double câblage et la capacité excédentaire peuvent maintenir la charge de travail active. Les clients sur un seul hôte sont affectés jusqu'à ce que l'alimentation revienne, que l'hôte redémarre ou que la charge de travail soit transférée.

Les preuves qui amélioreraient la confiance incluent un plan d'alimentation au niveau du locataire, la couverture de double alimentation, le dernier test intégré et un journal de notification client.

La deuxième est la perte de l'amont. AS136175 a actuellement un seul voisin global observé. L'adhésion au SIX est utile, mais à elle seule, elle ne fournit pas une route alternative complète. Une défaillance de la session de transit peut faire disparaître le /24 de l'entreprise tandis que les serveurs continuent de fonctionner. Un deuxième amont routé de manière indépendante, un basculement de préfixe testé et une participation active au serveur de routes réduiraient ce risque.

La troisième est la défaillance du stock de matériel. Un disque peut être remplacé rapidement s'il y a une pièce de rechange compatible dans le même bâtiment et que l'intervention à distance est autorisée. Cela peut prendre beaucoup plus de temps si la pièce doit être obtenue, expédiée, réceptionnée et installée. Les générations de serveurs dédiés plus anciennes augmentent l'importance des pièces de rechange stockées. La mesure pertinente est le temps de réparation et de restauration de la charge de travail, pas le type de CPU dans le tableau des ventes.

La quatrième est la défaillance du support. Un canal de tickets peut être ouvert pendant que le diagnostic, l'escalade au fournisseur ou l'approbation commerciale attendent. Les clients ont besoin d'une voie de gravité qui atteigne une personne ayant autorité pour contacter Wowrack, Iron Mountain ou un autre fournisseur réseau. Des objectifs publiés d'accusé de réception, de diagnostic, de solution provisoire et de restauration rendraient le support 24 h/24 mesurable.

La cinquième est la défaillance de facturation ou de politique. Un serveur valide peut être supprimé selon les délais d'impayé publiés, et l'application des utilisations interdites peut suspendre le service. Des contacts de facturation multiples, des délais de préavis plus longs pour les clients établis, une voie d'appel et une période de grâce pour l'exportation empêcheraient qu'un différend administratif ne se transforme en une perte de données irréversible.

La sixième est la défaillance de migration. Un client peut découvrir pendant une panne que sa sauvegarde est locale, que l'exportation du panneau de contrôle est incomplète, que la réputation IP ne peut pas être transférée et que les identifiants DNS sont enfermés dans le même compte. Une restauration réussie chez un autre fournisseur est une preuve de portabilité plus solide qu'une promesse de migration gratuite à l'entrée.

Ces défaillances affectent différents groupes. Le propriétaire d'un site personnel peut tolérer plusieurs heures et reconstruire à partir d'une copie récente. Un revendeur peut avoir des dizaines de clients en aval et aucun accès direct à l'opérateur de l'installation. Une entreprise utilisant un VPS non géré peut être entièrement responsable de son application tout en dépendant de ServerHosh pour la récupération de l'hôte et le routage. Un client de serveur dédié peut être propriétaire de la pile logicielle mais ne pas avoir d'accès physique pour remplacer le matériel.

Ce qui améliorerait matériellement la confiance

ServerHosh publie déjà plus de détails d'infrastructure que de nombreux fournisseurs à bas coût. Il nomme des installations, des fournisseurs de transit, des classes d'équipement, une adhésion à des échanges, des affirmations sur les sauvegardes et des limites de produits. L'amélioration suivante n'est pas un chiffre de disponibilité plus élevé. C'est un ensemble plus réduit de faits actuels et délimités.

Pour chaque emplacement, l'entreprise pourrait publier l'opérateur d'installation et l'adresse, son rôle en tant que propriétaire ou locataire, le nombre de baies actives, la puissance contractée et disponible, la politique de pièces de rechange pour serveurs et réseau, les sessions amont, les ports d'échange, la disponibilité IPv4 et IPv6 pour les clients, la politique DDoS, le préavis de maintenance et l'escalade d'intervention à distance. Des schémas sensibles ou des détails clients ne sont pas nécessaires. Des faits opérationnels agrégés suffiraient.

Pour chaque classe de produit, il pourrait séparer la vitesse d'interface de la politique d'utilisation équitable et du débit engagé; définir si le service est géré; spécifier la fréquence, l'emplacement et la conservation des sauvegardes; établir des objectifs de récupération; et joindre une politique cohérente de remboursement, de suspension et de suppression à la commande. Une page de statut pourrait nommer les services et les emplacements, conserver l'historique des incidents et rapporter la maintenance sans exposer d'informations de sécurité.

La preuve la plus solide serait un exercice de routine. Retirer une route de transit et montrer la route alternative. Restaurer un compte d'hébergement mutualisé à partir du deuxième niveau de sauvegarde. Évacuer un VPS d'un hôte défaillant. Remplacer un disque de serveur dédié par intervention à distance. Reconstruire une application client représentative dans un autre emplacement. Rendre compte du temps, des limitations et des actions correctives.

Jusqu'à ce que ces preuves soient publiques, ServerHosh doit être évalué comme un petit fournisseur d'hébergement actif avec une empreinte réseau réelle mais concentrée, un accès crédible à la capacité de centres de données tiers et une incertitude substantielle quant à la redondance au niveau du locataire. Ses prix bas et son vaste catalogue peuvent convenir à des charges de travail conçues pour être remplaçables. Ils ne doivent pas être confondus avec un service de récupération multisite géré.

La leçon physique est la plus importante. ServerHosh peut empaqueter des cœurs, du stockage et de la bande passante dans un produit mensuel pratique, mais il ne peut pas virtualiser l'absence d'une baie défaillante, d'une route retirée, d'une pièce de rechange indisponible, d'une facture oubliée ou d'une restauration non testée. Les clients n'achètent de la résilience que lorsque ces dépendances sont nommées, réparties en domaines de défaillance indépendants et exercées avant que la fenêtre de réparation ne commence.