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

Résumé

• ServerHosh présente un vaste catalogue d'hébergement mutualisé, de VPS et de serveurs dédiés depuis une base commerciale indienne, avec des sites annoncés à Seattle, Philadelphie, Phoenix et Londres. La preuve réseau indépendante la plus claire actuelle est plus restreinte: AS136175 annonce un IPv4 /24 via Wowrack et dispose d'une connexion 1 Gbps au Seattle Internet Exchange.
• La société déclare posséder le matériel et les équipements réseau, exploiter un transit direct et utiliser des suites privées dans l'installation de Wowrack à Seattle et dans Iron Mountain LON-1. Les archives publiques établissent les installations et certains espaces d'adressage étiquetés ServerHosh, mais ne divulguent pas le nombre de baies, la puissance souscrite, la capacité de basculement utilisable, le stock de rechange ou la salle londonienne précise.
• Un label de port serveur à 1 Gbps ou 10 Gbps n'est pas une capacité dédiée de bout en bout. Les propres conditions d'utilisation raisonnable de ServerHosh permettent une restriction de port pour les charges de travail soutenues à large bande passante, tandis que la route globale actuelle pour son propre ASN n'expose qu'un seul amont observé et aucun espace IPv6 annoncé.
• La récupération est également divisée par produit. L'hébergement mutualisé annonce une sauvegarde quotidienne à deux niveaux et une migration cPanel, tandis que les conditions générales qualifient les VPS et serveurs dédiés de non gérés et imposent de courtes fenêtres de suppression après non-paiement. Les clients ont donc besoin d'un plan indépendant de restauration, d'exportation et de continuité de facturation plutôt que de considérer un faible prix mensuel comme un produit de résilience complet.

Une vitrine cloud avec une chaîne d'approvisionnement physique

ServerHosh présente l'infrastructure comme une liste de petits choix mensuels. Sapage d'accueil actuellepromeut l'hébergement mutualisé à partir de 1,99 $, les machines virtuelles aux États-Unis et en Grande-Bretagne, et les serveurs dédiés en France, à Seattle et à Londres. Le catalogue s'étend 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, un disque et une vitesse de port sans jamais voir une baie, un disjoncteur, un plateau de fibre ou la personne qui remplacera un disque défaillant.

Cette séparation est normale dans l'hébergement. C'est aussi là que se situe 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 réseaux amont, 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 d'alimentation, les installations de refroidissement, les bureaux de sécurité et l'accès à distance. La capacité visible pour un acheteur est la tranche finale d'une chaîne plus longue.

La société se décrit comme un fournisseur d'hébergement indien opérant depuis 2012. Sapage À proposnomme Anirban Ghosh et Srabanti Paul comme propriétaires et liste les rôles opérationnels et de support. Un registre des sociétés distinct rapporte 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 privée. Elles ne doivent pas être amalgamées en une affirmation selon laquelle la société actuelle a les mêmes actifs, contrats ou structure d'exploitation depuis 2012.

Le bureau orienté client est également séparé des machines. Lapage de contactde ServerHosh donne une adresse à Kolkata et un numéro de téléphone indien. Il annonce un support 24 heures sur 24, tandis que les ventes et la facturation sont listées comme fonctionnant du lundi au samedi. Les machines sont présentées comme étant à des milliers de kilomètres. Il s'agit d'un arrangement de service distribué: administration commerciale en Inde, capacité matérielle et réseau dans des installations étrangères, et demande client pouvant venir de n'importe où.

Cet arrangement 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, louer un transit IP et placer les clients sur des machines virtuelles. Il peut combiner des frais généraux réduits avec un support direct et des choix de produits restreints. Mais le même arrangement crée plusieurs limites qu'un acheteur doit cartographier. Qui possède le serveur? Qui détient le contrat de l'installation? 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 ou que chaque affirmation doit être acceptée. C'est que l'exploitation 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 nommées existent. Pourtant, la quantité de capacité vendable, le chemin d'un ticket à un serveur réparé et la capacité à restaurer les données client après une panne courante ne sont pas publiés sous une forme que le client peut tester.

La preuve actuelle la plus solide est une seule route Seattle

ServerHosh a son propre système autonome, AS136175. L'enregistrement APNICidentifie Serverhosh Internet Service, une adresse à Kolkata et Anirban Ghosh comme contact administratif et technique. L'enregistrement attribue au système autonome un code de pays Pays-Bas tandis que l'enregistrement d'organisation associé dit 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 tableau de routage en direct est compact. Leprofil AS136175de Hurricane Electric montrait un préfixe IPv4 annoncé, 209.90.232.0/24, un voisin IPv4 observé, AS23033 de Wowrack, et aucun préfixe IPv6 annoncé le 10 juillet 2026. Lamesure de statut de routagede RIPE montrait indépendamment le même espace IPv4 de 256 adresses, aucun espace IPv6 et un voisin observé. Sonhistorique des préfixes annoncésmontrait ce /24 continuellement visible pendant la fenêtre de requête de deux semaines précédente.

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

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

L'entrée d'échange doit être lue attentivement. Elle ne montre pas ServerHosh livrant des routes aux serveurs de route SIX, et elle ne transforme pas un port d'échange 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 remplissent des fonctions différentes. Une charge de travail client a toujours besoin d'une route complète vers les réseaux qui ne peering pas avec ServerHosh. Le seul voisin observé globalement reste Wowrack.

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

Cela ne prouve pas que les liens plus grands sont absents. Un fournisseur d'hébergement peut utiliser des adresses attribuées par le fournisseur annoncées sous l'ASN d'un fournisseur, des VLAN privés, un transit protégé ou une capacité que les collecteurs ne peuvent pas attribuer à son propre système autonome. La preuve actuelle établit moins: ServerHosh contrôle une route IPv4 visible via Wowrack et une connexion d'échange à Seattle. Un inventaire de circuit actuel, un résumé de configuration de routeur et un graphique de trafic séparé par emplacement seraient nécessaires pour valider la déclaration de capacité plus grande.

L'IPv6 illustre la même distinction. SIX et PeeringDB attribuent à ServerHosh une adresse d'échange IPv6, donc une interface compatible IPv6 existe sur la structure d'échange. Pourtant, la société n'annonce aucun préfixe client IPv6 dans la table mondiale. Une adresse LAN d'échange est une infrastructure pour le peering; ce n'est pas une allocation routée qu'un client VPS peut nécessairement utiliser.

Un acheteur nécessitant un service double pile devrait donc tester une machine virtuelle provisionnée et confirmer un préfixe IPv6, une route par défaut, un DNS inverse et un comportement de basculement, et ne pas se fier uniquement à l'enregistrement d'échange.

L'installation de Seattle appartient au domaine d'exploitation du propriétaire

ServerHosh déclare avoir une suite privée avec Wowrack à Seattle. La proprefiche technique SEA1de Wowrack décrit une installation de 18 000 pieds carrés, 450 baies au 12201 Tukwila International Boulevard avec une capacité électrique de 3 MW, refroidissement N+1, systèmes UPS et générateur, accès à distance, connectivité neutre vis-à-vis des opérateurs et accès SIX sur site. L'historique de l'entreprisede Wowrack indique qu'elle s'est agrandie pour occuper une installation de 3 MW et 18 000 pieds carrés à Seattle en 2014.

Le chevauchement entre ces chiffres et la propre description de ServerHosh est frappant. Les deux citent 18 000 pieds carrés, 3 MW, redondance de l'installation de refroidissement, densité élevée des baies, accès SIX et le même contexte général d'exploitation à Seattle. Cela soutient l'interprétation que ServerHosh décrit les capacités de l'installation Wowrack dans lequel il loue de l'espace, et non un bâtiment qu'il possède. Cela est cohérent avec sa déclaration selon laquelle il se trouve en colocation à Seattle et avec la relation BGP publique avec Wowrack.

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

L'adresse physique nécessite également de la prudence. Un annuaire commercial associe ServerHosh à une adresse Seattle d'apparence plus ancienne, tandis que les documents actuels de Wowrack placent 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. Elle n'identifie toujours pas la cage, la suite, le nombre de baies ou la puissance d'armoire de ServerHosh.

Un client recherchant une assurance 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 à partir duquel la responsabilité de ServerHosh commence.

Lesrègles de l'installationde Wowrack montrent pourquoi la frontière a des conséquences opérationnelles. Les livraisons doivent être organisé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. C'est une gouvernance de colocation ordinaire, mais cela signifie qu'un remplacement de matériel ServerHosh peut dépendre des procédures du fournisseur, de l'acceptation de l'expédition et de la coordination à distance avant que son propre personnel puisse terminer la réparation.

La frontière de propriété a donc 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 un transit réseau visible dans BGP. ServerHosh déclare posséder le matériel et les équipements réseau dans son empreinte. 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 contrôlant 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é déclare que sa suite privée se trouve dans Iron Mountain LON-1. Leprofil officiel 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, plus des armoires individuelles, des cages, des suites privées et une assistance à distance 24 heures sur 24. Unaperçu distinct des emplacementsd'Iron Mountain liste LON-1 au 724-729 Dundee Road, avec des refroidisseurs, générateurs et systèmes UPS N+1.

Ces enregistrements établissent LON-1 et ses grandes capacités d'installation. Ils n'établissent pas quelle salle, baie ou chemin électrique ServerHosh occupe. ServerHosh n'est pas listé avec une installation d'interconnexion à Londres dans son enregistrement PeeringDB, et AS136175 n'expose pas de route Londres. Aucun de ces faits ne réfute une suite privée. Les déploiements clients privés n'apparaissent souvent pas dans les bases de données d'installations publiques, et un fournisseur peut utiliser un espace d'adressage annoncé par un autre réseau.

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

La distinction importe car l'emplacement du centre de données et l'origine du réseau sont des faits différents. Un serveur ServerHosh pourrait se trouver à LON-1 tandis que son trafic est transporté 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 londoniennes à faible latence établissent une présence réseau britannique à un niveau utile, mais un acheteur nécessitant une résidence à Slough a besoin d'une confirmation contractuelle du site physique et de la liste des sous-fournisseurs.

Lapage actuelle des serveurs dédiés UKde ServerHosh nomme explicitement Iron Mountain LON-1 et annonce des systèmes Ryzen avec des connexions 1 Gbps non mesurées. Pourtant, lecatalogue de commandeslié montrait zéro unité disponible pour chaque configuration de serveur dédié UK affichée lors de la vérification. Zéro stock ne prouve pas que l'emplacement est inactif. Cela montre 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'assemblage personnalisé.

Le catalogue VPS londonien fait une promesse plus large. ServerHosh annonce desmachines virtuelles 10 Gbpsavec bande passante non mesurée, protection DDoS et disponibilité réseau 99,99 %. La page indique que l'hôte physique dispose d'un port full-duplex 10 Gbps redondant 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 sur des commutateurs indépendants, le seuil d'utilisation raisonnable, ou le débit mesuré disponible lors d'une attaque ou d'une panne amont.

Ce n'est pas une objection sémantique. Un client achetant une machine virtuelle ne peut pas consommer plus de capacité physique que l'hôte, le commutateur et la liaison montante ne peuvent en fournir. Si vingt invités partagent un port hôte 10 Gbps, leurs interfaces annoncées peuvent toutes être 10 Gbps alors que le débit utilisable simultané est beaucoup plus faible. Si un deuxième port est un standby sur la même pile de commutateurs, il protège un câble ou une interface mais pas le commutateur, le transporteur ou l'installation.

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

La capacité installée n'est pas la même que la capacité à vendre

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 plans sur une plateforme Intel E3-1270v6, d'un gigaoctet à 70 gigaoctets de stockage, avec cPanel, CloudLinux, LiteSpeed et une connexion serveur 1 Gbps. Lapage VPS stockageindique que chaque serveur physique dispose de quatre disques SATA 4 To en RAID 10 et vend des allocations virtuelles de 500 Go à 4 To. La page des serveurs dédiés États-Unis liste des Xeon E3 plus anciens et des machines double Xeon à Seattle aux côtés de choix Ryzen et Xeon plus récents à Philadelphie et du stock prévu à Phoenix.

Il n'y a rien d'intrinsèquement mauvais avec du matériel plus ancien. Un serveur amorti peut rendre un plan d'hébergement à faible coût viable, et les plateformes matures peuvent être stables lorsqu'elles sont entretenues. L'âge change l'équation opérationnelle. Les cartes mères de remplacement, la mémoire compatible, les contrôleurs RAID et les disques d'entreprise peuvent être plus difficiles à trouver rapidement. La consommation électrique par unité de travail est souvent plus élevée. Le support du firmware peut être limité.

La bonne question n'est pas de savoir si chaque machine est neuve, mais si le fournisseur dispose de pièces de rechange testées et peut restaurer la charge de travail dans un délai annoncé.

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

La capacité virtuelle ajoute une autre couche. Un plan VPS alloue des cœurs virtuels et de la mémoire, mais les pages publiques ne précisent pas le nombre d'invités par hôte, la politique de contention CPU, le sur-engagement mémoire, l'objectif de latence de stockage ou le ratio d'hôtes de réserve. Un fournisseur peut vendre plus de cœurs virtuels nominaux que de cœurs physiques car les clients culminent rarement ensemble. C'est le moteur économique de l'hébergement VPS abordable.

Cela devient un problème de panne 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 d'espace pour les absorber.

Le stockage a une arithmétique similaire. Quatre disques 4 To en RAID 10 fournissent environ la moitié de la capacité brute avant formatage et espace réservé, et non 16 To de stockage protégé vendable. Si un fournisseur attribue 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 divulgue pas la méthode de provisionnement. Le RAID 10 peut tolérer certaines pannes de disque, mais la reconstruction consomme des E/S et une deuxième panne dans le mauvais miroir peut encore perdre la matrice.

La capacité réservée aux reconstructions et migrations fait partie de la capacité de service utilisable même si elle ne produit pas de facture.

Les étiquettes de bande passante sont particulièrement faciles à surinterpréter. ServerHosh utilise à plusieurs reprises « non mesuré » à côté de ports 1 Gbps et 10 Gbps. Sesconditions généralesdéfinissent le service non mesuré comme soumis à une utilisation raisonnable, interdisent plusieurs applications à large bande passante continue et permettent une restriction de vitesse de port lorsque l'utilisation s'écarte du schéma défini. Cela fait du non mesuré une description de facturation, pas une garantie de débit soutenu à la vitesse de ligne.

Un client devrait donc demander quatre chiffres de capacité distincts: la vitesse d'interface présentée au serveur; toute allocation de transfert mensuelle ou seuil d'utilisation raisonnable; le débit engagé en cas de contention ordinaire; et le débit minimal attendu après une panne de lien, de commutateur ou d'hôte. Seul le premier est important dans le catalogue. Sans les trois autres, une étiquette 10 Gbps décrit une condition d'interface locale maximale, pas le débit disponible pour restaurer des téraoctets de données lors d'un incident.

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

Les deux opérateurs d'installations nommés publient des descriptions techniques crédibles. Wowrack indique que Seattle SEA1 dispose de 3 MW de puissance, d'arrangements UPS 2N ou N+1, d'une alimentation de secours par générateur, d'un refroidissement N+1 et d'un 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 manière dont ses propres équipements sont connectés à l'intérieur de ces sites.

Un serveur à double cordon peut recevoir deux chemins d'alimentation. Un serveur bas coût à cordon unique connecté à une seule barrette d'alimentation de baie ne le peut pas. Deux barrettes de baie peuvent encore partager un panneau en amont. Une suite peut être limitée à une enveloppe de kilowatts souscrite même si le bâtiment dispose de mégawatts de capacité installée. Une fois que le locataire atteint cette enveloppe, il peut avoir des unités de baie vides mais aucune puissance disponible pour un autre serveur.

ServerHosh ne publie pas sa puissance souscrite, la charge actuelle de ses baies, la carte des chemins d'alimentation ou le pourcentage d'équipement à double cordon. Il ne précise 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 répondre à 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'exploitant du bâtiment peut maintenir des refroidisseurs N+1, mais le locataire contrôle les panneaux d'obturation, le flux d'air, l'obstruction des câbles, la densité des baies 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 température moyenne cible. Une assurance utile pour le client serait de rapporter la température d'entrée à la baie, les seuils d'alarme, le responsable 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'alimentation reste la cause la plus fréquente de pannes graves et sévères de centres de données dans l'analyse des pannes 2025d'Uptime Intelligence. Le rapport prévient également que les données sur les pannes sont incomplètes et que les défaillances des procédures du personnel comptent. C'est le bon niveau d'inférence ici. Cela ne montre pas que ServerHosh ou l'une ou l'autre installation a subi un événement électrique particulier. Cela montre pourquoi un pourcentage de disponibilité non qualifié est plus faible qu'un chemin testé à travers la perte de service public, le démarrage du générateur, le fonctionnement de l'UPS, la distribution en baie et le redémarrage du serveur.

La maintenance crée un test plus ordinaire qu'une catastrophe. Les générateurs ont besoin de tests en charge. Les modules UPS nécessitent un entretien. Les commutateurs ont besoin de modifications logicielles. Les disques ont besoin d'être remplacés. Un fournisseur résilient devrait pouvoir isoler un composant sans arrêter la charge de travail hébergée, ou expliquer l'interruption prévue s'il ne le peut pas. ServerHosh ne publie pas de calendrier de maintenance, de délai de préavis, d'exclusion de maintenance dans sa revendication de disponibilité ou 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, un e-mail et une base de données ensemble car ils partagent un seul serveur. Un utilisateur 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 de remplacement. L'installation redondante de l'installation réduit le risque commun, mais seule la réplication de l'application vers 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é du transit est plus étroite que la liste des emplacements

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

Pour le propre ASN de ServerHosh, le chemin Internet visible est monotrace via Wowrack. La connexion SIX fournit une attache d'échange séparée mais ne semble pas annoncer le seul préfixe client de la société via les serveurs de route de l'échange. Si la session de transit Wowrack, le transfert interne ou le routeur ServerHosh échoue, le /24 peut être retiré même si le bâtiment et les serveurs restent sous tension.

La page réseau de la société nomme Hurricane Electric comme fournisseur de transit principal à 100 Gbps, mais les collecteurs publics n'ont pas montré AS6939 adjacent à AS136175 le 10 juillet 2026. Plusieurs explications sont possibles: le lien peut servir des adresses attribuées par le fournisseur, se trouver derrière Wowrack, être inactif, ou être une capacité d'installation décrite comme capacité locative. Le registre public ne peut pas choisir 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 également un décalage d'échelle entre un port SIX 1 Gbps visible et des pages produits offrant plusieurs serveurs 1 Gbps ou 10 Gbps. Le port d'échange n'est pas la seule capacité réseau de l'installation, donc le catalogue n'est pas mathématiquement impossible. Cela signifie que l'échange ne peut pas transporter simultanément le débit d'interface annoncé complet de chaque client. La même chose s'applique à toute connexion hôte 10 Gbps partagée entre machines virtuelles.

La protection DDoS introduit une autre dépendance. Les pages produits annoncent un service protégé, et le catalogue de commandes londonien fait référence à un chiffre de protection standard de 600 Gbps sur certains systèmes. Ce nombre peut décrire la capacité agrégée d'une plateforme de mitigation plutôt que le trafic livrable à un seul serveur. La protection efficace 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 n'est défini publiquement.

Le test de redondance pratique comporte trois parties. Premièrement, le préfixe peut-il rester joignable globalement après la désactivation d'une session amont? Deuxièmement, le client peut-il recevoir suffisamment de trafic propre après mitigation pour que l'application reste utile? Troisièmement, les systèmes DNS, de panneau de contrôle et de tickets peuvent-ils toujours être atteints pendant la même panne? Ne réussir que la première laisse le service opérationnel sur le papier mais inutilisable pour le client.

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

Les serveurs physiques tombent en panne de manière spécifique. Les disques accumulent des erreurs. Les ventilateurs se bloquent. 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 du fait que la pièce de rechange exacte est à proximité, testée et accessible.

ServerHosh déclare posséder son matériel et ses équipements réseau. Cela peut être un avantage car l'entreprise n'attend pas qu'un cloud de détail expose une option de remplacement. La propriété place également le risque d'inventaire sur un fournisseur relativement petit. Le catalogue public ne montre pas les quantités de rechange, les hôtes de réserve, l'endurance des disques, la couverture de garantie ou la distribution par âge de l'équipement installé.

À Seattle, une réparation peut nécessiter que ServerHosh diagnostique la panne à distance, ouvre la bonne demande Wowrack, identifie l'armoire, autorise le travail et fournisse ou expédie la pièce. Wowrack annonce une assistance à distance 24 heures sur 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'accuser réception de la plupart des demandes d'assistance à distance dans les 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 remplacement.

Les serveurs dédiés configurés sur mesure rendent le problème d'inventaire visible avant une panne. ServerHosh donne un délai de livraison de un à trois jours ouvrés et marque plusieurs configurations indisponibles. Un remplacement en cas de panne peut ne pas suivre le délai de vente, surtout pour une plateforme Xeon plus ancienne ou une configuration de disque propre au client. Un engagement utile spécifierait l'objectif de réparation par composant, les pièces détenues sur site et la solution de repli si un remplacement exact ne peut être trouvé.

La récupération VPS peut être plus rapide si le fournisseur dispose d'un 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 les 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 firmware correct, une désinfection du disque, un isolement du client et un contrôle de la 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 précisent pas la conservation, 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. Gardez la configuration de la machine en dehors de l'hôte, automatisez les reconstructions, maintenez des images logicielles à jour et testez la restauration de l'application vers un autre fournisseur ou emplacement. Cela déplace la récupération de l'attente d'une carte mère particulière vers le lancement d'une capacité connue bonne ailleurs.

Les revendications de sauvegarde divergent fortement selon le produit

La page d'accueil de ServerHosh indique qu'il effectue des sauvegardes quotidiennes pour l'hébergement. La page d'hébergement mutualisé NVMe est plus spécifique, listant une sauvegarde quotidienne à 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 sont non gérés et ne reçoivent qu'un support de base. Elles ne promettent pas de sauvegarde gérée par le fournisseur pour ces produits.

Cette distinction est facile à manquer car « sauvegarde gratuite » apparaît à côté de certaines promotions VPS. Un acheteur a besoin de 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 du dernier test de restauration réussi. Aucun de ces détails n'est publié dans l'ensemble des produits.

RAID n'est pas un substitut à la sauvegarde. Une redondance en miroir ou en bande peut maintenir un volume en fonctionnement après une panne de disque, mais elle reproduit également la suppression accidentelle, la corruption et le ransomware. Si le serveur entier, le contrôleur ou la baie est perdu, la matrice est perdue avec lui. Un instantané de l'hôte peut échouer pour la même raison s'il réside sur le même pool de stockage.

Leguide contre les ransomwaresde la CISA recommande des sauvegardes hors ligne, chiffrées et des tests d'intégrité et de restauration réguliers. Leguide de planification d'urgencedu NIST traite également le stockage alternatif, le traitement alternatif, les télécommunications et la sauvegarde comme des parties liées de la récupération. Ce sont des repères généraux, pas une preuve que ServerHosh les suit ou les échoue.

Pour ServerHosh, la preuve décisive serait un calendrier de sauvegarde spécifique au produit et un résultat de restauration. Un rapport d'hébergement mutualisé pourrait indiquer quand chaque niveau a été terminé, où se trouve la deuxième copie et combien de temps a pris une restauration complète de compte. Une option VPS pourrait définir les 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 du fournisseur à moins que la commande n'en ajoute expressément une.

Lapage de disponibilité publiquene comble pas cette lacune. Elle présente un calendrier sur sept jours et un calculateur de plage de dates mais n'expose aucun service nommé, historique d'incidents, répartition par emplacement ou mesures 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é de 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 la perte de données. Il y avait 64 avis et aucun avis au cours des 12 mois précédents lors de la vérification. Les avis sont autosélectionnés, couvrent différents produits et périodes, et ne peuvent pas établir un taux de panne actuel. Ils identifient les questions que les acheteurs devraient tester: temps de réponse, interprétation de la bande passante et responsabilité de restauration.

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

Toutes les pannes ne commencent pas dans une salle de données. Les conditions de ServerHosh stipulent qu'un serveur dédié peut être définitivement résilié 24 heures après une facture impayée, un VPS supprimé après 72 heures, et un hébergement mutualisé ou revendeur résilié 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 manqué ou une facture contestée peut devenir un événement de perte de données alors que la machine physique reste saine.

Le risque est amplifié par la division des heures de support. Le support technique est annoncé en continu, mais la facturation est listée du lundi au samedi. Une suspension en fin de semaine peut nécessiter une autorité commerciale que le répondant technique ne détient pas. Les documents publics ne précisent pas de voie d'escalade pour une erreur de facturation menaçant une suppression imminente.

Le langage de remboursement est incohérent selon les pages. Lapolitique de remboursement généraledonne une garantie de 15 jours pour l'hébergement mutualisé mensuel, 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 possible remboursement partiel. La page VPS Londres offre un remboursement complet dans les 48 heures et un remboursement partiel plus tard. La page dédiée UK indique qu'un remboursement est disponible si la livraison n'a pas lieu dans les 48 heures. Un acheteur ne peut pas combiner en toute sécurité la phrase la plus favorable de chaque page.

Les conditions commerciales applicables devraient être jointes à la commande spécifique. Elles devraient indiquer la livraison, l'annulation, le crédit de service, l'avis de suspension, le délai de suppression et le traitement des paiements contestés. Pour une charge de travail importante, le client devrait également conserver plus d'un contact de facturation autorisé, surveiller la livraison des factures en dehors du domaine hébergé et éviter de stocker la seule copie de l'e-mail de facturation sur le service qui pourrait être suspendu.

C'est une question d'économie d'hébergement, pas une simple administration. Les prix bas dépendent de la standardisation, de l'automatisation et du contrôle strict des abus et des non-paiements. ServerHosh examine manuellement les commandes, limite les utilisations à large bande passante et peut résilier une activité interdite. Ces politiques protègent la réputation IP rare, le temps de support et la capacité de transit. Elles créent également un besoin de 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.

La société dispose d'adresses distinctes pour le support, les ventes, la facturation et les abus, ce qui est mieux qu'une boîte aux lettres générique unique. Elle ne publie pas de niveaux de gravité, d'objectifs de réponse, de rôles d'incident nommés, d'escalade téléphonique pour les clients existants ou de pratique de rapport post-incident. La disponibilité 24 heures sur 24 décrit donc le canal, pas un temps garanti pour le diagnostic ou la réparation.

La migration est possible, mais la portabilité est conditionnelle

ServerHosh annonce des réductions pour les clients venant d'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 les comptes, bases de données, boîtes aux lettres et paramètres dans un format qu'un autre serveur cPanel peut restaurer. Cela signifie également que l'offre de migration n'est pas universelle.

Un site WordPress peut souvent être déplacé 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, un réseau privé et un grand disque. Un serveur dédié peut utiliser une disposition RAID ou un système d'exploitation qui ne peut pas être copié directement sur du matériel différent. Les pages publiques de ServerHosh ne définissent pas comment ces charges de travail sont exportées ou si le personnel aidera après le déménagement 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. Passer de l'espace Seattle de ServerHosh ou d'une plage londonienne annoncée par un fournisseur peut nécessiter un renumérotage, des modifications DNS, un nouveau DNS inverse et des mises à jour des listes d'autorisation. La réputation des e-mails liée à une adresse ne se transfère pas automatiquement. Un déménagement effectué pendant une panne peut donc prendre plus de temps que la copie des données.

Les panneaux de contrôle réduisent l'administration de routine mais peuvent créer leurs propres dépendances. ServerHosh utilise cPanel pour l'hébergement mutualisé et annonce des panneaux de machines virtuelles 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 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 d'urgence comme une combinaison de mesures techniques, de procédures et d'emplacements de traitement alternatifs, pas simplement un fichier de sauvegarde. Pour un client ServerHosh, un test de portabilité réaliste provisionnerait une machine propre ailleurs, restaurerait l'application, ferait pivoter les secrets, changerait le DNS et mesurerait 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 le courrier, les certificats et les rappels de paiement.

La récupération multisite n'est pas établie en commandant deux emplacements ServerHosh à moins que leurs dépendances ne soient cartographiées. 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. C'est une diversité de fournisseurs prometteuse, mais le client doit encore confirmer que les comptes, plans de contrôle, sauvegardes et facturations ne sont pas partagés d'une manière qui permette à un seul incident commercial ou de sécurité de désactiver les deux.

La meilleure position de sortie est celle qui fonctionne sans intervention du fournisseur. Cela signifie des copies de données actuelles, des enregistrements de configuration, le contrôle du domaine, une surveillance indépendante, une destination testée et suffisamment de bande passante pour se déplacer 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 couches. La société et l'administration des clients sont en Inde. Les pages produits publiques placent les machines aux États-Unis et au Royaume-Uni, avec des offres supplémentaires mentionnant la France et les Pays-Bas. Les enregistrements réseau montrent un /24 annoncé par 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 surveillance et de panneau de contrôle en dehors de la ville du serveur.

Lapolitique de confidentialitéde la société indique qu'elle traite les noms, coordonnées, adresses IP, informations commerciales, détails de paiement et communications, et que les données relationnelles 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 d'hébergement, les pays de traitement, un calendrier de suppression fixe, les mécanismes de transfert international ou l'installation utilisée pour chaque produit.

Cela est distinct 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 sesdirectives sur les responsables et sous-traitants du traitementque les rôles dépendent de qui détermine les finalités et les moyens du traitement, et que la sous-traitance modifie les responsabilités. Sesdirectives sur les transferts internationauxtraitent spécifiquement du transfert d'informations par un sous-traitant à un sous-traitant à l'étranger.

Le cadre de protection des données de l'Inde a également évolué 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 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é à partir de la ville dans un titre de produit uniquement.

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

La preuve londonienne montre pourquoi. Une page peut nommer Iron Mountain LON-1 tandis qu'un préfixe étiqueté ServerHosh et un hôte de verre de visée 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 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 nécessite les quatre.

Six pannes révèlent le véritable service

La première panne est une interruption de baie ou d'installation. Si le chemin d'alimentation souscrit, la zone de refroidissement ou l'armoire de ServerHosh tombe en panne, la redondance sous-jacente du bâtiment peut limiter l'incident, mais seul un équipement à double cordon et une capacité de réserve peuvent maintenir la charge de travail en vie. 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 déplacée.

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

La deuxième est la perte amont. AS136175 a actuellement un voisin global observé. L'adhésion à SIX est utile mais ne fournit pas en soi une route alternative complète. Une défaillance de session de transit peut retirer le /24 de la société alors que les serveurs continuent de fonctionner. Un deuxième amont routé indépendamment, un basculement de préfixe testé et une participation actuelle au serveur de route réduiraient ce risque.

La troisième est la panne de stock matériel. Un disque peut être remplacé rapidement si une pièce de rechange compatible se trouve dans le même bâtiment et que l'assistance à distance est autorisée. Cela peut prendre beaucoup plus de temps si la pièce doit être approvisionnée, expédiée, admise et installée. Les générations de serveurs dédiés plus anciennes augmentent l'importance des pièces de rechange en stock. 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 de vente.

La quatrième est la panne de support. Un canal de tickets peut être ouvert tandis que le diagnostic, l'escalade du fournisseur ou l'approbation commerciale attendent. Les clients ont besoin d'un chemin de gravité qui atteigne quelqu'un habilité à contacter Wowrack, Iron Mountain ou un autre fournisseur de réseau. Des objectifs publiés pour l'accusé de réception, le diagnostic, le contournement et la restauration rendraient le support 24 heures sur 24 mesurable.

La cinquième est la panne de facturation ou de politique. Un serveur valide peut être supprimé dans les délais de non-paiement publiés, et l'application de l'utilisation interdite peut suspendre le service. Plusieurs contacts de facturation, un préavis plus long pour les clients établis, une voie de recours et un délai de grâce pour l'exportation empêcheraient un différend administratif de devenir une perte de données irréversible.

La sixième est la panne de migration. Un client peut découvrir lors d'une panne que sa sauvegarde est locale, que son exportation du panneau de contrôle est incomplète, que sa réputation IP ne peut pas être déplacée et que ses identifiants DNS sont piégés dans le même compte. Une restauration réussie vers un autre fournisseur est une preuve plus solide de portabilité qu'une promesse de migration entrante gratuite.

Ces pannes affectent différents groupes. Un propriétaire de 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 posséder la pile logicielle mais n'avoir aucun accès physique pour remplacer le matériel.

Ce qui améliorerait considérablement la confiance

ServerHosh publie déjà plus de détails d'infrastructure que de nombreux hébergeurs économiques. Il nomme les installations, les fournisseurs de transit, les classes d'équipement, l'adhésion à l'échange, les revendications de sauvegarde et les limites de produit. La prochaine amélioration n'est pas un chiffre de disponibilité plus grand. C'est un ensemble plus restreint de faits actuels et délimités.

Pour chaque emplacement, l'entreprise pourrait publier l'opérateur de l'installation et l'adresse, son rôle en tant que propriétaire ou locataire, le nombre actif de baies, la puissance souscrite et disponible, la politique de rechange serveur et réseau, les sessions amont, les ports d'échange, la disponibilité IPv4 et IPv6 client, la politique DDoS, l'avis de maintenance et l'escalade de l'assistance à distance. Les diagrammes sensibles et les détails clients sont inutiles. 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 raisonnable 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; énoncer les objectifs de récupération; et attacher une politique cohérente de remboursement, suspension et suppression à la commande. Une page de statut pourrait nommer les services et emplacements, conserver l'historique des incidents et signaler la maintenance sans exposer d'informations de sécurité.

La preuve la plus solide serait un exercice de routine. Retirez un chemin de transit et montrez la route alternative. Restaurez un compte d'hébergement mutualisé à partir du deuxième niveau de sauvegarde. Évacuez un VPS d'un hôte défaillant. Remplacez un disque de serveur dédié via une assistance à distance. Reconstruisez une application client représentative dans un autre emplacement. Rapportez le temps, les limitations et les actions correctives.

Jusqu'à ce que ces preuves soient publiques, ServerHosh devrait ê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 autour de la redondance au niveau locataire. Ses prix bas et son large menu peuvent convenir aux 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 une baie défaillante, une route retirée, une pièce de rechange indisponible, une facture manquée ou une restauration non testée. Les clients n'achètent de la résilience que lorsque ces dépendances sont nommées, divisées en domaines de défaillance indépendants et exercées avant que la fenêtre de réparation ne commence.