PB级SMB存储数据迁移至AWS S3并保留文件创建元数据方案咨询

方案1：优化AWS DataSync配置（最推荐的托管方案） #

你之前提到DataSync丢失元数据，其实可以通过配置让它保留SMB原始元数据：

• DataSync默认会将SMB文件的修改时间同步到S3对象的LastModified字段
• 对于原始创建时间等其他元数据，可在DataSync任务的元数据映射设置中，将SMB的creation_time映射为S3的自定义元数据（比如x-amz-meta-original-creation-time）
• 配置步骤：创建DataSync任务时，进入"配置设置"->"元数据"，勾选"创建时间"并指定自定义元数据键名
• 优势：完全托管，无需自行维护服务器，DataSync支持专用网络通道（Direct Connect/VPN），迁移速度能支撑1PB级规模，故障自动重试
• 注意：S3的系统字段CreationDate是对象在S3的创建时间，无法修改，原始创建时间只能存在自定义元数据中，可告知分析人员通过aws s3api head-object --bucket <bucket-name> --key <object-key>命令读取

方案2：FSx for Windows File Server + S3批量操作（过渡式方案） #

如果必须通过FSx中转，建议用S3 Batch Operations替代Lambda（Lambda并发限制不适合1PB级批量处理）：

1. 用DataSync将SMB数据迁移至FSx for Windows File Server：FSx会完整保留SMB的所有元数据（包括创建时间、权限等）
2. 生成FSx文件清单：用PowerShell或AWS CLI遍历FSx文件系统，导出包含文件路径、原始创建时间的CSV清单
3. 创建S3 Batch Operations任务：选择"复制对象"操作，结合自定义脚本（或AWS SDK），将FSx文件上传至S3时，把原始创建时间写入自定义元数据

• 优势：FSx中转可保留完整的Windows元数据，适合需要先做数据清洗/整理的场景；S3 Batch Operations支持大规模批量处理，无并发瓶颈
• 劣势：多了FSx的存储成本，迁移流程增加中转步骤

方案3：EC2集群批量脚本（高度自定义方案） #

如果需要完全自定义元数据映射逻辑，可采用EC2集群并行处理：

1. 用Robocopy或DataSync将SMB数据同步到EC2挂载的大存储（比如EBS卷、FSx或S3兼容存储网关）
2. 在EC2上部署批量上传脚本（比如Python的boto3库），并行读取文件元数据（通过os.stat或PowerShell的Get-Item），上传至S3时添加自定义元数据
3. 用Auto Scaling Group扩展EC2实例数量，提升迁移速度

• 优势：可完全自定义元数据处理逻辑，适配特殊格式的元数据
• 劣势：需要自行维护EC2集群，处理并发、故障恢复和带宽优化，运维成本较高

关键注意事项 #

• 带宽优化：1PB数据建议用AWS Direct Connect或Snowball Edge设备，避免公网带宽瓶颈，缩短迁移周期
• 元数据格式统一：将原始创建时间转换为ISO 8601格式（比如2023-10-05T14:48:00Z），方便批处理工具解析
• 小批量测试：先迁移10GB以内的测试数据，验证元数据是否正确保留，再启动大规模迁移

内容的提问来源于stack exchange，提问作者matthew altenburg