Large migrations · Verification · 进度条背后的证据
在云之间移动数百 GB：您如何知道每个文件已到达？
在 500 GB 时，“上传看起来已完成”并不是证据。可靠的迁移需要持久的库存、每个对象的状态转换、中断后的可重复恢复以及来自目的地本身的证明。
更新日期 ; 16 分钟读完.
简短回答
FileArk 将库分为每个文件的记录和持久的队列消息。工作人员复制一次交付，存储返回的目标 ID，验证大小，读回确切的对象，并将 SHA-256 与源有效负载进行比较。只有在这些检查和数据库更新成功之后，记录才会被验证，消息才会被确认。
为什么规模改变了“工作”的含义
十个文件很容易检查。一万个文件不是。大型个人库可以组合小型文档、数 GB 视频、空文件、嵌套文件夹、Unicode 名称、存档项目和云本机格式。一次失败可能隐藏在令人印象深刻的百分比中。
总计有用但不完整。两个库可以显示相同的表观大小，而其中一个库缺少对象或包含由某些不相关文件平衡的截断对象。在本机文档导出或排除的提供程序对象之后，文件计数也可能有所不同。
有用的事实单位是文件作业：读取了哪个源对象、创建了哪个目标对象、比较了哪些字节、验证何时完成以及是否有任何尝试仍未解决。
完整的 FileArk 生命周期，带注释
当接受 Start 时，API 首先将扫描作业写入 MongoDB，然后将持久扫描消息发布到持久的 RabbitMQ 队列，并启用发布者确认。如果发布失败，作业将被标记为“失败”，并且 API 报告它无法安全地将扫描排队。
扫描器对两个提供程序进行身份验证，清点所选源，根据发现的字节检查有限目标配额，并为每个源文件更新插入数据库记录。它发布持久迁移消息，并仅在发布成功后将扫描标记为完成。
迁移工作人员使用手动确认和预取计数为 1。在读取、上传、重新读取、验证和保留内容时，交付仍处于未确认状态。因此，停止的连接或进程可以将未完成的工作返回到队列。
数据库行是一个清单项，而不是一次性簿记
每个文件记录都从“待处理”开始，在尝试期间移动到“进行中”，仅在验证后才达到“已上传”。尝试计数、上次尝试时间、错误详细信息、目标对象 ID、SHA-256 摘要、验证方法和 VerifiedAt 仍附加到记录中。
完成的记录作为进度和审计跟踪保留在数据库中。 “划掉文件”意味着受控状态改变，而不是删除证据。重复队列传送检查该状态并立即确认已用 VerifiedAt 标记为“已上传”的记录。
三次尝试失败后，持续性问题将变为“失败”，并带有尝试周期的完成时间戳。这使得异常可见，并防止有害消息在仪表板卡住时永远旋转。
Pending
→ InProgress (attempt recorded)
→ destination ID stored
→ destination size matches
→ exact destination object re-downloaded
→ source SHA-256 == destination SHA-256
→ Uploaded + VerifiedAt persisted
→ queue message acknowledged为什么一个文件可能会被多次传送
可靠队列通常提供至少一次交付，而不是跨云 API、消息代理和数据库的神奇的一次性承诺。在 OneDrive 或 Google Drive 接受上传之后、工作人员写入完成之前，可能会发生崩溃。
FileArk 通过幂等记录和目标恢复来处理这种不确定性。工作人员首先检查记录是否已经验证。如果没有，它可以使用存储的目标ID或搜索预期目标路径和中断结果的确切大小，然后决定再次上传。
然后，恢复候选对象将接受相同的精确对象哈希验证。找到熟悉的文件名是不够的。关键是将中断的尝试重新转化为证据，而不是乐观的成功。
在目的地和工人身上检查容量
在发布每个文件作业之前，扫描程序会汇总非负源元数据大小，并在提供商提供有限配额时将要求与目标报告的剩余存储进行比较。尺寸过小的目标无法扫描，而不是将工作送入已知的死胡同。
该数字是预检，而不是保证：帐户活动可能会在运行期间消耗空间，提供商配额报告可能会滞后，导出的云原生文件可能不具有传统的源大小。提供程序强制执行和每个文件的错误处理仍然处于活动状态。
您的计算机磁盘不用于暂存。在迁移工作线程上，只有在卷有空间容纳预期对象加上 2 GB 的保留空间后，高于内存阈值的文件才会被放置在隔离的临时目录中。无论尝试成功还是失败，临时内容都会在清理过程中被删除。
为什么目的地 ID 加上 SHA-256 很重要
文件名不是唯一的标识。目标可能已经包含两个具有相同可见名称的文件，或者元数据列表可能需要时间来解决。上传响应提供提供程序对象 ID，FileArk 在最终验证阶段之前存储该 ID。
工作人员跨源有效负载流计算 SHA-256，上传它，然后通过该 ID 打开确切的目标对象并再次计算 SHA-256。同等大小捕获明显的截断；相等的加密摘要是更强的字节级检查。
仅涵盖传输的文件表示形式。摘要无法验证共享规则、评论、版本、标签、快捷方式、保留设置或导出的 Google 文档如何为用户呈现。这些仍然是验收任务。
故意删除源代码超出了正常的成功路径
最安全的默认设置是仅复制，并且 FileArk 的删除选项处于关闭状态，除非您启用它。禁用删除后，验证失败无法删除原始文件，因为从未请求删除。
如果您故意启用移动后删除，则工作线程在调用源提供程序的删除操作之前仍会等待目标 ID、大小和 SHA-256 验证。对于不可替代或非常大的图书馆来说，更强有力的操作选择仍然是关闭该选项并使用人工批准的重叠期。
迁移回答“经过验证的副本是否到达？”保留回答“什么时候可以删除旧副本？”将它们视为具有单独证据的单独决定。
相同的控制模型在两个方向上都起作用
对于 OneDrive 到 Google Drive，源有效负载从 Microsoft Graph 读取，目标对象通过 Google Drive 返回的 ID 进行验证。对于 Google Drive 到 OneDrive，通过 Google Drive 下载或导出源，并通过 Microsoft Graph 读回新的 OneDrive 项目。
队列、数据库状态、有界尝试、容量预检、源摘要、目标 ID、目标摘要和确认顺序是方向中立的。提供程序适配器处理不同的上传、文件夹和内容 API。
不对称是内容语义。 Google 原生文档需要导出，并且两个平台都有特定于服务的共享和版本行为。字节验证的文件内容不应作为每个协作功能的完整克隆进行销售。
使用由四部分组成的验收计划
核对系统记录
查看已完成、待处理、进行中和失败的计数。任何失败的项目都不应该被放弃，因为总体百分比很高。
按风险抽样
打开最容易丢失的文件，以及大型媒体、档案、旧文档、非英文名称、嵌套路径和转换后的云本机文件。
验证目标行为
测试真实设备和用户的访问。重建所需的共享并确认 Office 或导出的 Google 文件按预期打开。
保持重叠期
在正常使用锻炼目的地的同时，保持来源可用且稳定。稍后做出任何取消或删除决定。
常见问题
FileArk 是否为每个文件使用队列？
是的。扫描器为每个源文件创建或重用数据库记录，并发布持久迁移消息。工作人员通过手动确认来提取这些消息。
队列消息何时被确认？
验证目标对象 ID、大小和 SHA-256 并保留 Uploaded 和 VerifiedAt 状态后。未完成的配送可以重新配送。
已完成的文件记录是否从数据库中删除？
不。完成是持久记录上的状态转换。该行保留目的地身份、验证证据、时间和尝试信息以进行进度和审核。
SHA-256 可以证明权限和版本已移动吗？
不会。它证明目标文件字节与传输的源有效负载匹配。共享、权限、版本、注释、标签、快捷方式和提供者本机行为需要单独验证。
OneDrive 到 Google Drive 的验证方式是否与反向验证方式相同？
核心规则在两个方向上都是相同的：源有效负载摘要、目标对象标识、目标大小、精确对象重新下载摘要、持久验证，然后队列确认。