摘要
- Lunanode 明显在运营：其当前网站提供多伦多虚拟机和存储，状态页面记录了直至 2026 年的事故和维护，AS394745 仍在公告，IPv4 和 IPv6 空间在公共路由数据中可见。
- 活跃的计算足迹似乎集中在多伦多。Lunanode 在 2023 年因数据中心成本大幅增加关闭了蒙特利尔和鲁贝，而一些较旧的 API 示例仍列出所有三个区域，不应视为当前容量。
- 弹性以分层形式提供，而非自动属性。卷、快照、浮动 IP、负载均衡器、亲和性控制和可下载映像帮助客户设计恢复，但大多数控制仍位于同一多伦多故障域内，除非客户在其他地方保留独立副本。
- 证据等级为中等。Lunanode 发布了异常有用的事故细节并展示了可信的网络记录，但未公开披露机架数量、可用电力、总安装计算资源、当前存储拓扑、合同维修目标、备件深度或第二个活跃计算区域。
云控制面板无法消除其背后的机房
Lunanode 的产品明显是云服务，而非简单的带登录的租用服务器。该公司的关于页面描述了一个基于 OpenStack 和 KVM 的平台，提供虚拟机、块卷、实时快照、浮动 IP 地址、虚拟网络、启动脚本、监控和 API。其虚拟机页面将服务分为通用型、内存优化型和计算优化型计划，并说明实例按小时计费。客户可以创建、调整、搁置、重镜像、救援和删除虚拟机，无需等待物理服务器订单。
这种抽象是真实且有价值的。它让小型软件公司可以租用服务器的一部分，让管理员将资本支出转化为运营支出，让项目在不再需要时释放计算资源。但它也使得物理依赖性容易被忽视。每个虚拟核心映射到特定机箱中的处理器插槽。每个本地磁盘映射到驱动器和控制器。每个块卷依赖于存储节点和它们之间的网络。每个公共地址依赖于路由、边缘设备、上游和设施的电力。每次维修依赖于人员、替换部件和对机架的访问。
Lunanode 自身的公开记录使得这一链条异常具体。当前的位置页面提到了多伦多，说明部署在 Cogent 多伦多设施内，并描述了 10 Gbps 网络、冗余上行链路和电源系统。它提到了双 Intel Xeon E5-2690 v2 处理器和 SSD RAID10 主机的固态硬盘。相关的基础设施页面表示客户可以选择本地 SSD 磁盘或分布式块存储，位于同一区域的虚拟机通过 10 Gbps 私有网络通信。
这些陈述确定了服务背后的硬件类型。但没有披露安装了多少设备、剩余多少容量、占据了多少个机架、预留了多少电力、有多少代主机仍在服役，或者是否每个工作负载都获得相同的存储和网络路径。位置页面上提到的处理器来自较早的服务器代次。这并不意味着它不可用；可靠的老旧硬件对于低成本托管来说可能具有经济合理性。但它意味着买方应区分明确指定的主机类型和持续更新的机群。
在这种情况下，云是在有限的多伦多部署之上的有用操作接口。Lunanode 控制其客户平台、虚拟机调度、存储服务、网络配置和支持决策。Cogent 控制重要的设施和上游条件。硬件供应商决定部件可用性。客户控制应用程序架构、独立备份以及在别处维护容量的决定。可靠性源自这四方的边界，而不仅仅是控制面板。
多伦多是当前运营的重心
Lunanode 当前基础设施故事中最重要的因素是地理集中。当前营销页面称云平台位于多伦多。更有决定性的是，虚拟机 API 文档指出 VM 创建的区域参数必须是toronto。当前的安全组文档也说明新组的区域必须为 Toronto。这些是比旧的地点列表更强有力的当前信号，因为它们描述了当前供应接口接受的内容。
其他 Lunanode 页面保留了历史痕迹。计划和区域 API 页面包含一个带有蒙特利尔、鲁贝和多伦多的示例响应。虚拟网络 API 页面同样显示了这三个名称。快照功能页面仍描述跨云位置的复制。这些页面本身都不能证明客户可以在 2026 年 7 月在蒙特利尔或鲁贝配置新的生产容量。
Lunanode 的状态历史解决了这一明显矛盾。2023 年初，该公司表示由于所使用数据中心大幅提高成本，正在关闭蒙特利尔和鲁贝。客户被告知在 2023 年 1 月 31 日之前将虚拟机和附加卷迁移到多伦多，请求帮助，或者如果多伦多不合适则寻求退款。后来的条目说明剩余在关闭地点的 VM 将被迁移到多伦多。当前仅多伦多的服务页面与该历史一致；三个区域的 API 示例最好视为过时文档。
此次关闭不仅仅是一个历史注脚。它揭示了供应商合同故障路径。Lunanode 不需要火灾、洪水或技术崩溃就失去了两个区域。商业投入发生了变化：设施变得显著昂贵。公司通过撤回容量和整合工作负载来回应。这是一个理性的商业决策，但它说明了为什么租用的基础设施永远无法独立于租约、电力价格、传输协议以及维持低利用率容量的经济性。
对于客户来说，影响取决于架构。一个具有配置自动化和外部数据副本的无状态应用可以移动。一个具有本地磁盘、固定地址、未记录的软件更改且未经过测试恢复的长期运行的 VM 可能成为一个迁移项目。一个为延迟或地理位置选择鲁贝的欧洲客户无法将多伦多视为等效替代。一个蒙特利尔客户可能仍留在加拿大，但面临不同的延迟、对等连接和灾难地理。供应商提供了迁移帮助和积分，但客户仍需承担应用层面的工作以及关于多伦多是否满足其需求的决策。
Lunanode 可以面向许多国家的客户销售和服务，同时将可见的计算平台运营在一个城市。公开显示的活跃物理容量并非全球分布。全球销售面与多区域基础设施是不同的事物。
低价格源于利用率、标准化和限制
Lunanode 的商业吸引力很直接。其当前的定价页面列出了每月几美元起的小型通用型和内存型 VM、更大的配置以及具有专用核心的计算优化型计划。块存储和快照存储按 GB 计费，额外公共地址按月计费，超额带宽按 GB 计费。因此，该服务适合个人项目、小型网站、开发系统、适度的商业应用以及无需大型云合同的工作负载。
低入门价格并非专用物理机的成本。而是托管池中一份份额的价格。供应商购买服务器、机架空间、网络端口、地址、存储介质和员工时间，然后将这些固定和半固定成本分摊给客户。盈利能力取决于占用率和利用率：必须有足够的客户为已安装的机群付费，而并非所有客户都能在同一瞬间以最大强度要求所有分配的资源，除非计划容量设计允许。
Lunanode 使其中一些控制可见。通用型和内存型计划使用虚拟核心；计算优化型计划宣传专用核心。带宽按账户和区域池化，统计入站和出站流量。服务条款规定超额带宽将计费，客户可以选择在超出池之前关闭 VM。搁置可释放 CPU 和内存，同时以较低成本保留存储和地址。这些不仅仅是计费细节。它们是将有限设备转化为可销售、看似弹性容量的机制。
因此，安装容量和可用容量并不相同。一个机架可能包含标称的核心处理器和 TB 级存储，但部分必须保留用于系统开销、存储复制、故障设备、维护、主机不平衡和客户预留。等待作为备件的服务器已安装但未产生正常收入。一个几乎满的机架可能仍有名义上的单元空间，但缺乏安全的电力余量。一个存储集群可能拥有原始磁盘空间，但由于复制和恢复预留而无法用于新客户数据。一个 10 Gbps 链路是端口速度，而非保证每个 VM 都能维持该速率到达每个目的地。
没有任何公开的 Lunanode 页面量化这些余量。当前的定价页面提供了目录，而非库存清单。控制面板可能向已验证用户显示计划可用性，但公开材料未说明每种类型可创建多少个实例、容量如何分布在主机之间，或者什么阈值触发硬件采购。因此，买方应将价格视为订购时的有效报价，而非无限扩充的证明。
这种经济框架也解释了 2023 年的区域收缩。小型供应商可以提供廉价容量，因为它避免了超大规模企业的开销。同样的纪律可能使低利用率或新近昂贵的所在地难以维持。廉价的按小时计算和永久的备用地理区域相互矛盾。需要两者的客户应支付独立容量并测试它，而不是假设基础 VM 价格包含一个空闲的辅助站点。
设施边界可见但仅部分描述
Lunanode 表示其多伦多位置位于 Cogent 设施内。其状态通知反复将 Cogent 认定为参与网络工作的数据中心或上游方。2026 年 6 月的一则通知警告可能因数据中心对边缘路由器进行软件升级而导致网络停机。2026 年 4 月的通知描述了类似的维护。2026 年 1 月的一起事故称，Lunanode 调查多伦多中断时，上游似乎在执行计划维护。
这种职责划分很重要。Lunanode 可以维护服务器及其自身网络设备，但无法独立防止设施边缘路由器升级或恢复故障的上游设备。2024 年 9 月，Lunanode 报告其服务器和网络设备保持通电且正常运行，但由于 Cogent 的电源问题导致网络设备受影响，外部连接离线。机架活着；服务不可达。仅关注 VM 电源状态的客户会错过实际故障。
公开材料支持在设计层面提供冗余上行链路和电源系统的说法。但未记录物理路径、运营商、断路器域、自动转换行为或最近的故障转移测试。冗余服务器电源仍可能馈入同一个故障配电路径。两个上行链路仍可能终止于同一个设备或穿过同一个维护域。第二个路由器仍可能依赖于同一个房间或上游。只有当其组件足够独立以经受所考虑的故障时，冗余才有意义。
状态历史显示了备件的价值和局限性。2023 年 3 月，Lunanode 表示一个多伦多虚拟机管理程序发生磁盘平面硬件故障，在将磁盘交换到备用物理服务器后恢复服务。2023 年 2 月，一个电源更换变得复杂，因为库存的更换件没有匹配的固件，因此两个电源必须在关机期间更换。这些条目是动手维修能力的具体证据。它们也表明拥有备件与拥有立即兼容的维修工具并非同一回事。
2020 年多伦多一次停电暴露了更广泛的故障域。Lunanode 报告 Cogent 位于 245 Consumers Road 的数据中心出现电涌，服务器重启，一个机架中的配电单元故障。一度有三个虚拟机管理程序和卷存储系统离线。该公司表示有两个备用服务器，如果受影响的机器均未启动，则无法快速将所有三个故障系统上线。后来它讨论了改进 Ceph 服务器的分组和更广泛的网络监控。这种披露程度很有用，因为它指出了恢复背后的有限资源：两个备件、三个受影响的机器和一个存储仲裁问题。
公开证据并未确定 2026 年存在相同的备件数量、机架布局或 Ceph 分组。将六年前的事故报告转变为当前库存是错误的。持久的教训是，Lunanode 的恢复依赖于现场拓扑、兼容部件和同时受影响的机器数量。这些约束条件在任何供应商中仍然相关，即使具体设备发生变化。
AS394745 增加了真实的网络证据，但并非完整路由图
Lunanode 不仅仅是一个位于其他公司匿名地址空间背后的品牌。ARIN 来源的记录和bgp.tools 的 AS394745 页面将 Lunanode Hosting Inc. 标识为自治系统 394745 的持有者。注册日期可追溯至 2015 年 12 月，组织记录可追溯至 2014 年。查询到 2026 年 7 月 12 日的公共路由数据显示该 AS 已公告。
路由视图很小但可信。RIPEstat 的公告前缀响应显示过去两周内公告了 172.81.176.0/21 和 IPv6 前缀 2602:ffb6::/36。其路由状态响应报告查询时有一个 IPv4 前缀、一个 IPv6 前缀和九个观察到的邻居。ARIN 来源的 whois 数据将 172.81.176.0/21 与 Lunanode 关联，Lunanode 当前多伦多测试地址位于该区块内。
IPv4 路由也说明了供应商边界。RIPEstat 的前缀概览在 7 月 12 日查询时显示 AS174 (Cogent) 和 AS394745 (Lunanode) 都与覆盖的 172.81.176.0/21 关联。对 AS394745 在该 /21 上的路由来源授权检查有效。混合来源视图与一个拥有自身身份但仍紧密耦合于 Cogent 路由的网络一致。这并非证明所有流量遵循同一路径，也未揭示私有会话或商业条款。
对等互联增加了另一块信息。Lunanode 的PeeringDB 记录列出了开放对等策略、两个 IPv4 前缀、一个 IPv6 前缀以及位于多伦多互联网交换节点的 10 Gbps 运营连接。它未披露流量水平或地理范围，也未列出网络配置文件的互联设施。PeeringDB 将 TorIX 端口定位于 Cologix TOR1。该公共交换节点的存在可以缩短到参与网络的路径并减少部分传输依赖。不应将其误解为第二个计算站点。位于交换节点设施的对等端口可以通过传输从城市其他位置的服务器到达。
bgp.tools 视图显示了一组已知对等点，包括 Hurricane Electric、OVH、Cloudflare、TekSavvy 等（查询日期附近）。此类列表展示了观察到的路由邻接关系；它们并不确定付费上游多样性、平等的 IPv4 和 IPv6 可达性、合同容量或故障转移性能。同一页面在一个摘要中仅显示 IPv6 分配为直接来源，而其详细策略视图包括两个协议的对等点。RIPEstat 显示了 IPv4 /21。路由收集器、时间和分类之间的差异是使用多个视图的原因，而非声明其中一个为完整拓扑的理由。
因此，公共网络结论是适度的。Lunanode 拥有自己的 AS、地址资源、有效的路由来源控制、活跃的 TorIX 端口和多个观察到的邻居。这比一个没有可见网络身份的托管站点更强有力的证据。然而，面向客户的多伦多服务多次依赖于 Cogent 设施和上游工作，公开记录未披露合同传输容量、物理路径多样性、边缘设备冗余或测量的故障转移。网络证据支持当前运营；它不支持城市无关弹性的说法。
存储选择会改变性能和故障域
Lunanode 为虚拟机的磁盘提供了两个概念上不同的位置：本地主机存储和可拆卸块卷。卷文档说明卷可以附加或拆卸，用作启动设备，在删除 VM 后保留，转换为映像或从映像转换，以及快照。HDD 卷单独定价，而 SSD 卷被描述为仅限多伦多。关于页面提到卷支持的 VM 可以使用 Ceph RADOS 分布式存储，并可能在硬件故障后自动疏散。
权衡很重要。本地 SSD 可以提供直接且经济的路径，但 VM 严重依赖于其主机的磁盘、控制器和文件系统。移动工作负载可能需要复制或移植存储。分布式卷可以将数据与单个计算主机分离，更容易在其他地方启动 VM。同时，它引入了一个共享存储平面。如果有足够的存储节点、网络链路或电源域同时发生故障，许多卷支持的 VM 可能同时受到影响。
Lunanode 的事故历史包含这两种模式的例子。2020 年 7 月的电力事件影响了卷存储系统，因为多台服务器离线。2023 年 9 月一个多伦多机架的停电影响了该机架中的块存储和 VM。2024 年 11 月和 2025 年 7 月的本地磁盘事故导致长时间的文件系统修复和少量 VM 上的客户数据损坏或丢失。这些并非证据表明某种存储选择始终更优。它们表明本地和分布式设计的故障方式不同。
2025 年 7 月的条目与客户责任特别相关。Lunanode 报告了一个多伦多 SSD 虚拟机管理程序的停机，延长了文件系统修复，无法提供早期恢复估计，最终四个虚拟机因磁盘损坏而丢失数据。它为受影响的用户提供了三个月停机和十二个月数据丢失的积分。积分可以承认损害；但无法重建客户数据。
供应商的条款明确界定了边界：快照功能存在，但 Lunanode 不会自动备份客户数据，并且免除数据丢失的责任。快照页面说明可以在虚拟机在线时拍摄快照，用于创建或重镜像虚拟机，以及从面板下载。最后一项功能是最重要的弹性特性之一，因为下载的映像可以离开供应商的直接故障域。
仅保存在同一多伦多环境中的快照仍面临账户丢失、控制平面故障、设施中断和供应商收缩的风险。该页面提及跨云位置复制快照反映了早期的多区域服务，不应假定当前提供地理分离。买方需要验证现在可用的目标是什么。如果多伦多是唯一的活跃区域，独立备份需要另一个存储供应商、另一个站点或客户控制的介质。
快照也具有应用程序限制。在数据库繁忙时拍摄的磁盘快照可能是崩溃一致的，而非事务一致的，除非应用程序静止或协调其自身备份。可下载映像如果无人测试恢复、记录加密密钥、捕获外部服务或知道如何在其他主机上调整网络配置，则可能毫无用处。控制面板提供了有用的原语。客户必须将其转化为恢复设计。
事故记录展示了实际故障路径
Lunanode 的状态页面是其公开证据中最有力的部分之一。它标识了当前和计划的工作，命名了受影响的虚拟机管理程序，描述了一些原因并经常记录恢复进度。该页面说超过六个月的项目可能被清除，尽管仍有相当多的历史可见。它不是经过认证的正常运行时间报告，但比通用的可靠性承诺更具信息量。
这些事故分为几个重复出现的类别。
设施和上游网络故障。2026 年 5 月，Lunanode 报告多伦多丢包，并说上游已确定原因。2026 年 4 月和 6 月的计划 Cogent 工作可能导致停机。2024 年 9 月，Cogent 的电源问题使 Lunanode 已通电的服务器与外界断开数小时。2023 年，一个多伦多机架因断路器问题断电。这些事件同时影响许多客户，可能使健康的 VM 不可达。
虚拟机管理程序硬件故障。档案记录了故障磁盘、RAID 控制器、电源、内存模块和异常主机错误。一些停机持续数分钟；其他需要长时间修复。只有当其存储、调度器、备用计算和网络路径仍然可用时，虚拟化平台才能移动或重建 VM。本地磁盘 VM 特别依赖于物理主机，除非数据已复制到别处。
共享存储故障。2020 年电力事件和 2023 年机架中断影响了块存储。分布式存储减少了对一个磁盘或主机的依赖，但相关的电力、网络或分组问题可能移除足够多的成员以中断服务。这是组件冗余与系统独立性之间的区别。
控制平面和辅助服务故障。2024 年涉及lndyn.com的域名暂停中断了服务，直到 Lunanode 将域名移出注册商。另一则 2024 年通知称，监控电子邮件错误将某些用户的通知发送给了其他人。Lunanode 还承认，当多伦多网络离线时，邮件警报未被发送，因为其邮件服务器位于多伦多，并建议改用 SMS、语音或 HTTP 警报。因此，中断可能损害用于报告中断的机制。
数据损坏和长时间修复。2024 年和 2025 年的 SSD 虚拟机管理程序事故表明，服务器恢复到在线状态并不保证每个客户磁盘完好。文件系统检查可能需要数小时，损坏的 VM 磁盘可能需要客户恢复。恢复时间和恢复点是分开的：电力可能在数据可用之前恢复，恢复的服务可能仍然丢失了最近的写入。
商业位置故障。蒙特利尔和鲁贝因设施成本上升而关闭。这通常不会显示在技术状态图上，但可能具有最大的长期影响，因为整个位置消失了。客户得到了通知和迁移选择，但他们无法仅通过重新启动来保留该区域。
不应将档案简化为简单的停机率。它不提供完整的分母、活跃 VM 数量、大多数事件的受影响客户数量，或者保证每个细微项目都已发布。较旧的项目可能已被删除。一些通知包含不一致的日期或印刷错误。例如，当前部分包括一个标有 2026 年 5 月 18 日但更新日期为 5 月 13 日的多伦多网络标题。这削弱了精确的时间顺序，但不会削弱存在丢包和上游干预的证据。
也不应将坦诚与糟糕运营混淆。小型供应商可能因为描述了所发生的事情而显得比沉默的竞争对手更容易发生故障。Lunanode 的条目显示技术人员更换部件、移动磁盘、监控维修和提供积分。正确使用记录是识别故障机制并询问它们现在如何缓解，而不是假装公共事故计数本身能预测下一次停机。
冗余以分层形式可用，大多位于一个城市内
Lunanode 为客户提供几个构建弹性的组件。浮动 IP 功能允许外部地址在 VM 之间移动。负载均衡器服务可以在多台机器之间分配 TCP、HTTP 或 HTTPS 流量，并在监控检测到问题后删除故障成员。安全组和私有网络支持分层应用。VM API 暴露了亲和组选项，其响应包括物理主机标识符，允许客户请求放置在不同的虚拟机管理程序上。
每个特性针对特定的故障。位于不同虚拟机管理程序上的两个应用服务器可以承受一台主机崩溃。浮动地址可以减少激活替换所需的网络更改。负载均衡器可以停止向异常成员发送请求。卷支持的启动可以将数据与故障计算主机分离。监控可以在用户报告问题之前通知操作员。
但没有任何一个特性能够自动承受多伦多的丢失。位于不同主机的两个 VM 可能共享同一机架、配电、存储集群、边缘路由器、设施和上游。同一区域的负载均衡器可能与其后端一起失效。浮动 IP 仅在区域网络仍能路由它时才有用。卷可以比 VM 删除更持久，但在存储平面或设施中断期间仍不可用。亲和性可以分散计算部署，但不会产生地理分离。
因此，客户需要将设计与他们关心的故障匹配。对于爱好网站，快照和重建 VM 的能力可能就足够了。对于商业网站，单独的应用实例、经过测试的数据库备份和外部 DNS 控制可能更合适。对于具有严格连续性要求的服务，第二个副本应位于其他供应商或其他独立运营的站点，并留有足够的预留容量来启动工作负载。
“冗余”一词应始终引发四个问题：针对什么冗余？位于何处？由谁控制？何时测试？Lunanode 对冗余上行链路的宣称可能防止链路故障。但可能无法防止 Cogent 维护或设施范围的网络问题。RAID10 防护某些驱动器故障。但它无法替代备份，也无法防止档案中的每个数据损坏事件。Ceph 复制防护某些节点故障。但当相关电力或存储成员发生故障时，它仍可能受到影响。
恢复也依赖于可用容量。自动疏散需要一个具有足够 CPU 和内存的存活主机。从快照恢复需要足够的存储和时间。将大型映像移动到外部依赖于带宽。替换故障主机需要兼容的库存。公开记录未说明 Lunanode 为这些操作维护了多少余量，因此具有固定恢复目标的客户应获得具体答案，而非从特性名称推断。
支持、计费和账户状态也是基础设施依赖项
Lunanode 指导具有基础设施问题的客户提交支持工单。其监控服务支持 HTTP、TLS 证书过期、ICMP、TCP 和 DNS 检查，并通过电子邮件、SMS、电话和 webhook 通知。这些是实用的工具，特别是当警报目的地位于多伦多服务之外时。2024 年的电子邮件事故证明了为什么独立的警报通道很重要。
公开页面未为普通云计划规定一般的响应时间或恢复时间承诺。状态页面通常显示进行中的工作，但它不是合同性的服务水平安排。不存在关于 24 小时值班人员、升级层级、远程操作员安排、优先级类别或保证更换窗口的公开声明。这并不意味着支持缺失；详细的事故更新证明了主动干预。但它意味着买方无法从公开材料中得出明确的支持目标。
计费也可能中断技术上健康的服务。Lunanode 基于账户信用运作。其计费 API显示剩余信用余额，而条款说明低信用邮件在信用达到零前至少 48 小时发送，余额变为负数后服务暂停，暂停前至少提前七天通知。因此，支付失败、过时的联系地址或未注意的通知可能成为可用性事件。
条款还保留了广泛的暂停和终止权，描述了退款处理，并说明终止会释放分配的资源并删除相关数据。客户应在将不可替代的数据放入单个账户之前理解这些规定。操作分离可能需要不仅仅两个 VM：可能需要离供应商的备份、独立的 DNS 和域控制、多个计费联系人、监控信用、记录访问恢复以及第二个运行地点。
支持集中度难以公开衡量。ARIN 和 PeeringDB 记录列出了技术联系人，但注册联系人并未揭示团队规模或轮班覆盖。没有可靠的公开证据量化 Lunanode 的员工人数、现场人员或支持队列。诚实的结论并非支持必然薄弱；而是员工冗余和升级深度仍未经验证。
加拿大所在地有用，但并非完整的主权答案
多伦多托管可能吸引希望将主 VM 磁盘和卷放在加拿大的客户。Lunanode 在 ARIN 记录中是一家加拿大公司，其当前服务页面将多伦多标识为当前计算位置。这比仅标记广阔区域的客户提供了更多所在地信息。
公司的隐私政策说明客户 VM、卷和映像内容作为用户数据存储，并描述了对访问和披露的限制。其数据隐私协议将 Lunanode 描述为相关情况下的处理者或子处理者，允许子处理者，并说明客户在购买服务时选择数据存储的国家。两份文件均来自 2018 年。它们仍公开发布，但其年龄和对国家选择的引用应与当前仅多伦多的供应证据相协调。
数据位置具有多个层面。主磁盘可能位于多伦多，而监控消息、支付记录、支持通信或客户管理的备份使用其他供应商和司法管辖区。客户可以从任何地方访问多伦多托管的数据。子处理者可能参与提供部分服务。域名注册、支付处理、短信传送和上游连接拥有各自的操作者边界。因此，加拿大存储是一个有意义的事实，而非完整的法律或操作结论。
2023 年的关闭也表明为何必须随时间监控所在地。鲁贝曾经提供法国位置；蒙特利尔提供了第二个加拿大城市。当两者都关闭时，客户必须接受多伦多或离开。合同或合规评估应确定批准的位置、通知期望、导出流程以及该位置被撤回时的必要响应。
在 Lunanode 上，可移植性相对具体。快照可以下载。客户可以上传自己的映像和安装介质。卷可以转换为映像。浮动 IP 可以在平台内分离，尽管该地址通常无法跟随客户到无关的供应商。如果客户实际行使这些控制，它们可以减少锁定。映像格式、加密密钥、DNS 区域、配置记录和最近的独立数据备份比在紧急情况下发现的导出按钮更有用。
因此，严肃的所在地评估应询问每个数据类位于何处、谁能访问、适用什么法律条款、备份如何离开多伦多、客户多快可以检索完整副本，以及该副本是否在其他地方成功启动。Lunanode 的公开文档提供了起点。它们并未为每个工作负载回答整个评估。
什么会提高证据等级
Lunanode 的公开足迹并非空白。它比对其适度营销存在的粗略阅读所暗示的要强。该公司拥有活跃的产品和定价页面、当前的多伦多配置说明、截至 2026 年的详细状态通知、活跃地址空间、AS394745、IPv4 和 IPv6 公告、TorIX 存在以及长期运行的控制面。这些都是运营中的小型云供应商的可信迹象。
等级止步于中等，因为最影响弹性的事实仍未披露。公开材料未说明活跃机架或虚拟机管理程序的数量、整个机群的当前服务器代次、合同电力、可用电力余量、存储节点数量、复制布局、备件主机数量、替换部件库存、传输合同、物理路径多样性、支持人员数量、客户数量、利用率、恢复目标或恢复测试结果。它显示了一个活跃的计算城市，且没有经过验证的客户故障转移辅助站点。
会提高等级的证据无需泄露敏感细节。Lunanode 可以发布当前架构说明，区分设施、机架、主机和存储故障域；确认客户工作负载是否占据多个电源域；识别上游多样性的类别；说明亲和性放置如何映射到机架；描述当前卷复制和疏散行为；并提供聚合可用性和事故指标。当前的备份和数据位置声明可以取代 2018 年文件和历史上多区域指令留下的模糊性。
对于客户，直接问题是实际的。VM 位于本地磁盘还是卷？副本位于不同的主机和机架？应用能否承受主机故障？备份是否在 Lunanode 和多伦多之外？它能否在其他虚拟机管理程序或其他供应商上恢复？当多伦多无法发送电子邮件时，监控是否仍会发出警报？谁关注账户信用？如果一个区域被撤回会发生什么？恢复过程中必须通过网络传输多少数据，上次测试花了多长时间？
Lunanode 的价值主张不需要它看起来像超大规模云。一个紧凑的加拿大供应商在价格、直接性、按小时计费和多伦多所在地很重要时可能是一个好的选择。证据支持这一更窄的主张。它不支持将低成本托管容量视为默认无位置或自愈。
核心基础设施事实很简单：Lunanode 销售的是对多伦多真实设施中真实机器的灵活接口。其自身历史显示了依赖于备用服务器、兼容电源、文件系统检查、存储仲裁、上游技术人员和客户迁移的维修。买家可以使用平台的快照、卷、负载均衡器、浮动地址和监控来构建弹性。最后一层仍然属于他们：保留独立副本，在别处预留运行位置，并在机架、路由、账户或商业合同迫使迁移前测试路径。