我目前正试图将当前位于本地SMB共享上的大约1 PB的数据迁移到AWS S3。我遇到的问题是在使用Datasync或将文件复制到S3存储桶时丢失了原始文件创建元数据。我需要对象存储配置中的文件，以供批处理分析人员使用。
我有一个解决方案-使用AWS CLI移动和创建用户定义的元数据
但我认为这不会大规模奏效。
其他建议是将数据迁移到AWS FSx，然后使用AWS Lambda移动到bucket。
任何帮助或建议都会很棒。
我有一个解决方案-[…]来移动和创建用户定义的元数据
；CLI"；部分，我同意。S3是对象存储，而不是文件系统，所以您必须将自己的元数据添加到对象中以表达进一步的信息。
我认为[AWS CLI]不会大规模工作。
对于这样一个规模的项目，您将需要一个可以在至少一台计算机上扩展的幂等和高性能解决方案。
迁移大约1 PB的数据
PB是大量的数据。你应该先运行一些数字，看看你在当前上传链接上上传1000000GB数据的速度有多快。千兆位的理想速度是125MB/s，比如说，8000000秒，大约是92.59天。你们有千兆上行链路吗？或者你愿意在3个月内慢慢地、持续地这样做吗？
如果这听起来比你愿意等待上传的数据更多，可以考虑https://aws.amazon.com/snowball/.要点是，他们会给你一个NAS设备，你把数据上传到它上，然后他们会把它运回来。
将数据迁移到AWS FSx，然后使用AWS Lambda移动到bucket。
PB是大量数据，即使是从AWS组件到AWS组件。如果S3是数据的期望最终位置，那么它也成为数据的理想入口点。归根结底；将数据迁移到AWS FSx"；是与"；将数据上传到S3〃，除了涉及到文件系统，您必须向上传者公开这些文件系统并确保其安全。另一方面，S3将在谁是瓶颈的竞争中横向扩展您的网络。现在，如果想要文件系统中的数据，请仔细考虑FSX。但如果你想在S3，但它是从那里开始的。
很难提供一堆编程建议，因为这是一个大问题，但无论你做什么，都要尝试明智的计划，因为你不想意识到你必须重做几天、几周或几个月的数据传输。确保你有一种重新启动传输过程的方法，而不必重新传输超过必要的字节，因为这将是限制因素。这项任务可以通过持久存储支持的工作池和工作队列系统很好地实现。从小处着手，放慢你的流程——无论你是否必须自己编写代码——并确保你第一次就做对了，这样你就不必从头开始。