AWS DataSyncの検証で使用するチェックサムの計算タイミングを確認してみた

AWS DataSyncの検証で使用するチェックサムの計算タイミングを確認してみた

ONLY_FILES_TRANSFERREDでは転送元ロケーションのメタデータのチェックサムの再計算が行われないため、最終差分同期時はPOINT_IN_TIME_CONSISTENTを使用しよう
Clock Icon2025.02.24

DataSyncのチェックサム計算を行う際のタイミングはいつなのか気になる

こんにちは、のんピ(@non____97)です。

皆さんはDataSyncでファイル転送をするとき、検証で使用されるチェックサムの計算がどのタイミングで行われるのか気になったことはありますか? 私はあります。

DataSyncでは転送中および、オプションによっては転送完了後にメタデータのチェックサムを用いた検証を行います。

推奨されているオプションでは以下のように紹介されています。

転送されたデータのみを確認 (推奨) — DataSync 転送元の場所で転送されたファイルとメタデータのチェックサムを計算します。転送の最後に DataSync 、このチェックサムを転送先のファイルに対して計算されたチェックサムと比較します。

AWS DataSyncデータ整合性の検証方法を設定する - AWS DataSync

Black Beltの資料でも紹介されています。

30.AWS DataSync におけるデータの整合性の検証.png

抜粋 : AWS Black Belt Online Seminar - AWS DataSync

ただし、いずれの資料もチェックサムの計算タイミングについては言及されていません。

どのタイミングのチェックサムを使用するのかは非常に重要です。例えば、転送中に計算されたチェックサムを使用するのであれば、送信先もしくは送信元のファイルが転送完了後に更新された場合に転送完了後に発生したファイルのズレを検知することができません。

実際にどのようなタイミングでチェックサムの計算をしているのか確認してみます。

いきなりまとめ

  • データの検証がONLY_FILES_TRANSFERREDで、転送完了後に転送元ファイルが更新された場合は、転送元と転送先ファイルのズレには気づけない
    • 転送元ロケーションのメタデータのチェックサムはファイル転送時に行われ、転送完了後の検証ではそれを再利用していると推測
  • データの検証がONLY_FILES_TRANSFERREDで、転送完了後に転送先ファイルが更新された場合は、転送元と転送先ファイルのズレには気づける
    • 転送先ロケーションのファイルのチェックサム計算は、検証のタイミングで再計算されていると推測
  • データの検証がPOINT_IN_TIME_CONSISTENTの場合は、転送完了後に転送元ファイルが更新された場合であっても、転送元と転送先ファイルのズレに気づける
    • POINT_IN_TIME_CONSISTENTは全てのファイルの転送完了後に転送元と転送先を再度スキャンしてメタデータのチェックサムの再計算を行うと推測
  • ファイルサーバー移行時の最終差分同期のタイミングでは、POINT_IN_TIME_CONSISTENTを使用するのが良さそう
  • 全てのファイルの転送完了後に、検証を行う
  • 検証を行う順番は転送が完了した順番ではない
  • DataSyncは一つのファイルの転送が完了したら、次のファイルの転送を行うのではなく、同時に複数ファイルを並列で転送する
  • DataSyncは実データの転送が完了したタイミングでメタデータの転送を行う
  • DataSyncが出力するログはリアルタイムで転送の様子を確認することはできない
    • 転送量やファイル数によってはタスクの実行が完了したタイミングでまとめて出力される

やってみた

検証環境

検証環境は以下のとおりです。

AWS DataSyncのSMBファイルサーバーのロケーションではSMBファイル共有名にマルチバイト文字を含めることができない件検証環境構成図.png

以下記事で検証した環境をそのまま再利用します。

https://dev.classmethod.jp/articles/aws-datasync-smb-share-name-multibyte-character-limitation/

DataSyncを用いてAD DCのCドライブ上のファイルをAmazon FSx for NetApp ONTAP上に転送させます。

Cドライブ上にはファイルサイズが小さいものと大きいものとの2パターンを用意し、小さいファイルの転送が完了したタイミングで、小さいファイルに追記をします。

DataSyncタスクとロケーションの確認

DataSyncタスクとロケーションを確認します。

DataSyncタスクは以下のとおりです。

>  aws datasync describe-task --task arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e
{
    "TaskArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e",
    "Status": "AVAILABLE",
    "Name": "sys_integ_task",
    "SourceLocationArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:location/loc-0ba98bf492f9c5770",
    "DestinationLocationArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:location/loc-0930a9e677aac820f",
    "CloudWatchLogGroupArn": "arn:aws:logs:us-east-1:<AWSアカウントID>:log-group:/aws/datasync",
    "SourceNetworkInterfaceArns": [],
    "DestinationNetworkInterfaceArns": [
        "arn:aws:ec2:us-east-1:<AWSアカウントID>:network-interface/eni-0158d820db08f9670",
        "arn:aws:ec2:us-east-1:<AWSアカウントID>:network-interface/eni-035e14dd9e986d005",
        "arn:aws:ec2:us-east-1:<AWSアカウントID>:network-interface/eni-084c5cfe434dce7de",
        "arn:aws:ec2:us-east-1:<AWSアカウントID>:network-interface/eni-0ca7a05b54e726db3"
    ],
    "Options": {
        "VerifyMode": "ONLY_FILES_TRANSFERRED",
        "OverwriteMode": "ALWAYS",
        "Atime": "BEST_EFFORT",
        "Mtime": "PRESERVE",
        "Uid": "NONE",
        "Gid": "NONE",
        "PreserveDeletedFiles": "PRESERVE",
        "PreserveDevices": "NONE",
        "PosixPermissions": "NONE",
        "BytesPerSecond": 10485,
        "TaskQueueing": "ENABLED",
        "LogLevel": "TRANSFER",
        "TransferMode": "CHANGED",
        "SecurityDescriptorCopyFlags": "OWNER_DACL",
        "ObjectTags": "PRESERVE"
    },
    "Excludes": [],
    "CreationTime": "2025-02-13T10:44:49.471000+09:00",
    "Includes": [
        {
            "FilterType": "SIMPLE_PATTERN",
            "Value": "/system/*"
        }
    ],
    "TaskMode": "BASIC"
}

ファイル更新の時間を確保するべく、転送になるべく時間が掛かるように帯域を絞っています。

ロケーションは以下のとおりです。

2.送信元と送信先ロケーション.png

DataSyncタスクの実行 (対象ファイル転送完了後に転送元ファイルの更新 × ONLY_FILES_TRANSFERRED)

それではまず、対象ファイルの転送が完了したタイミングで転送元ファイルの更新をした場合の挙動を確認します。

送信元ロケーション内のファイルは以下のとおりです。

1.送信元ロケーションのファイル.png

test.txtの転送が完了し、他のファイルが転送されている間にtest.txtを更新します。

タスクを実行します。

3.タスクの実行.png

しばらく待つと実行ステータスが転送中になりました。

7.転送中.png

エクスプローラーで転送先ロケーションを確認すると、確かにファイルが転送されています。

8.転送されている.png

また、ASCII_64MiB.txtASCII_64MiB_2.txtASCII_64MiB_3.txtのサイズを見るといずれも64MiBに達していません。どうやらDataSyncは複数ファイルを並列で転送するようです。

また、ファイルの最終更新日時を確認するとASCII_64MiB.txtASCII_64MiB_2.txtASCII_64MiB_3.txtは現在の時刻ですが、転送が完了しているtest.txttest2.txtは転送元ロケーションのファイルの最終更新日時と一致していました。実データの転送が完了したタイミングでメタデータの転送を行うようですね。

ちなみにこのタイミングでCloudWatch Logsに出力されたログを確認しましたが、test.txtの転送が完了したという情報は記録されていませんでした。

2025-02-21T14:01:40.866+09:00 [INFO] Request to start task-00600a02964ae7f2e.

ASCII_64MiB.txtASCII_64MiB_2.txtASCII_64MiB_3.txtが転送中の隙に、転送元ロケーションのtest.txtを更新します。

9.送信元更新.png

更新後も転送先ロケーションでファイルが更新される様子はありません。

10.一度転送されたファイルは転送先でアップデートはかからない.png

そのまま待っていると、エラーなくDataSyncタスクが完了しました。

11転送完了.png

このタイミングでCloudWatch Logsに一気にログが出力されていました。

2025-02-21T14:01:40.866+09:00 [INFO] Request to start task-00600a02964ae7f2e.
2025-02-21T14:05:39.699+09:00 [NOTICE] Network bandwidth limit enabled for exec-01623f293ff7201ed at 8.4e-05 Gbps (0 MiB/s)
2025-02-21T14:05:39.699+09:00 [INFO] Execution exec-01623f293ff7201ed started.
2025-02-21T14:06:06.343+09:00 [NOTICE] Created directory /system
2025-02-21T14:06:07.809+09:00 [NOTICE] Transferred file /system/test2.txt, 5 bytes
2025-02-21T14:06:07.832+09:00 [NOTICE] Transferred file /system/test.txt, 5 bytes
2025-02-21T14:08:04.582+09:00 [NOTICE] Transferred file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-21T14:10:03.027+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-21T14:10:03.195+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-21T14:10:03.350+09:00 [NOTICE] Transferred directory metadata /system
2025-02-21T14:10:03.350+09:00 [NOTICE] Transferred directory metadata /
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified directory /
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified directory /system
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified file /system/test.txt, 5 bytes
2025-02-21T14:10:04.070+09:00 [NOTICE] Verified file /system/test2.txt, 5 bytes
2025-02-21T14:10:04.154+09:00 [INFO] Execution exec-01623f293ff7201ed finished with status Success.

ログから分かることは以下のとおりです。

  • 検証時にエラーは出ていない
  • 全てのファイルの転送完了後に、検証を行う
  • 検証を行う順番は転送が完了した順番ではない

なお、数秒間隔で更新していたのですが、タスクが完了したタイミングで一気に出力されたので、この程度の転送量、ファイル数ではリアルタイムで転送の様子を確認するのは難しそうです。

エクスプローラーで確認すると、更新したtest.txtは転送先に反映されていないことがわかります。

12.転送完了後のファイル.png

つまり、データの検証がONLY_FILES_TRANSFERREDで、転送完了後に転送元ファイルが更新された場合は、転送元と転送先ファイルのズレには気づけないことが分かりました。

おそらく、転送元ロケーションのメタデータのチェックサムはファイル転送時に行われ、転送完了後の検証ではそれを再利用しているのでしょう。

DataSyncタスクの実行 (対象ファイル転送完了後に転送先ファイルの更新 × ONLY_FILES_TRANSFERRED)

続いて、対象ファイルの転送が完了したタイミングで転送先ファイルの更新をした場合の挙動を確認します。

転送前のファイルの状態は以下のとおりです。転送先ロケーション配下のファイルは削除しています。

13.転送前のファイルの状態.png

DataSyncタスクの実行を行います。

14.DataSyncタスクの実行.png

数分待つと転送が開始されました。

15.転送開始.png

エクスプローラーを確認すると、ファイルの内容やファイルの最終更新日時やtest.txtが転送完了していることを確認できました。

16.送信先変更前.png

転送先ロケーションのtest.txtを更新します。

17.転送先変更後.png

更新完了後、DataSyncタスクの実行状態を確認しましたが、特にエラーにはなっていません。

18.まだエラーにはなっていない.png

CloudWatch Logsに出力されたログも以下のみです。

2025-02-21T14:18:41.406+09:00 [INFO] Request to start task-00600a02964ae7f2e.

転送終了直前のエクスプローラーの状態です。転送先ロケーションのファイルが修正されるという事象は発生していません。

19.まだエラーにはなっていない2.png

ログを見ると、実行開始をしたという情報だけ出力されていました。

2025-02-21T14:18:41.406+09:00 [INFO] Request to start task-00600a02964ae7f2e.
2025-02-21T14:20:31.462+09:00 [NOTICE] Network bandwidth limit enabled for exec-0efc87c74eb332815 at 8.4e-05 Gbps (0 MiB/s)
2025-02-21T14:20:31.462+09:00 [INFO] Execution exec-0efc87c74eb332815 started.

そのまま待つと、Transfer and verification completed. Verification detected mismatches. See a list of files with mismatches in CloudWatch logs. If no files are listed in CloudWatch logs, contact AWS Support.とエラーになりました。

20.エラーになった.png

ログを見てみましょう。

2025-02-21T14:18:41.406+09:00 [INFO] Request to start task-00600a02964ae7f2e.
2025-02-21T14:20:31.462+09:00 [NOTICE] Network bandwidth limit enabled for exec-0efc87c74eb332815 at 8.4e-05 Gbps (0 MiB/s)
2025-02-21T14:20:31.462+09:00 [INFO] Execution exec-0efc87c74eb332815 started.
2025-02-21T14:20:33.085+09:00 [NOTICE] Transferred file /system/test.txt, 13 bytes
2025-02-21T14:20:33.086+09:00 [NOTICE] Transferred file /system/test2.txt, 5 bytes
2025-02-21T14:22:30.577+09:00 [NOTICE] Transferred file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-21T14:24:29.219+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-21T14:24:29.253+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-21T14:24:29.389+09:00 [NOTICE] Transferred directory metadata /system
2025-02-21T14:24:29.884+09:00 [NOTICE] Verified directory /system
2025-02-21T14:24:29.884+09:00 [NOTICE] Verified file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-21T14:24:29.884+09:00 [NOTICE] Verified file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-21T14:24:29.884+09:00 [NOTICE] Verified file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-21T14:24:29.884+09:00 [NOTICE] Verified file /system/test2.txt, 5 bytes
2025-02-21T14:24:29.884+09:00 [NOTICE] Verification failed <> /system/test.txt
2025-02-21T14:24:29.884+09:00 [NOTICE] /system/test.txt srcMeta: type=R mode=0755 uid=65534 gid=65534 size=13 atime=1740114443/743982500 mtime=1740114443/743982500 extAttrsHash=3379933532
2025-02-21T14:24:29.884+09:00 [NOTICE] srcHash: 80ab83942616cfac650edce9e2d49648fd29c98b1ff0ad9b5c0216ec86e36675
2025-02-21T14:24:29.884+09:00 [NOTICE] /system/test.txt dstMeta: type=R mode=0755 uid=65534 gid=65534 size=22 atime=1740115340/634256000 mtime=1740115340/634256000 extAttrsHash=3379933532
2025-02-21T14:24:29.884+09:00 [NOTICE] dstHash: d3ecf63f674c0691d45a9e92226aad07400188444e85722dee8b148a4f3a79e5
2025-02-21T14:24:29.951+09:00 [INFO] Execution exec-0efc87c74eb332815 finished with status Transfer and verification completed. Verification detected mismatches. See a list of files with mismatches in CloudWatch logs. If no files are listed in CloudWatch logs, contact AWS Support..

はい、転送先ロケーションと転送元ロケーションのtest.txtの検証に失敗したことが分かります。

つまり、データの検証がONLY_FILES_TRANSFERREDで、転送完了後に転送先ファイルが更新された場合は、転送元と転送先ファイルのズレには気づけることが分かりました。

このことから転送先ロケーションのファイルのチェックサム計算は、検証のタイミングで再計算されているようです。

転送元でファイルを1秒間隔で更新しながらDataSyncタスクを実行 × ONLY_FILES_TRANSFERRED

転送元でファイルを1秒間隔で更新しながらDataSyncタスクを実行した場合はどうなるのでしょうか。

実際に試してみます。

以下のように1秒間隔で転送元ロケーションのファイルを更新し続けます。

while ($true) {
    Get-Date -Format "yyyy-MM-dd HH:mm:ss" | Out-File -Append "C:\system\test3.txt"
    Start-Sleep -Seconds 1
}

転送元ロケーションと転送先ロケーションの状態は以下のとおりです。

21.転送開始前.png

この状態でDataSyncタスクの実行を開始します。

22.実行中のタスク.png

数分待つとtest3.txtの転送が完了しました。

23.転送開始.png

ファイル内の内容見るに、早速転送元と転送先でズレが生じていますね。

そのまま、エラーなくDataSyncのタスク実行が完了しました。

25.転送時にエラーが発生していないこと.png

エクスプローラーを確認すると以下のとおりです。ズレているままですね。

24.転送完了.png

CloudWatch Logsに出力sれたログは以下のとおりです。

2025-02-24T09:36:57.316+09:00 [INFO] Request to start task-00600a02964ae7f2e.
2025-02-24T09:38:39.549+09:00 [NOTICE] Network bandwidth limit enabled for exec-0706ec578bbf0129d at 8.4e-05 Gbps (0 MiB/s)
2025-02-24T09:38:39.550+09:00 [INFO] Execution exec-0706ec578bbf0129d started.
2025-02-24T09:39:04.621+09:00 [INFO] Started logging in destination hostId: host-0a328e06cadbec8a1 for Execution exec-0706ec578bbf0129d
2025-02-24T09:39:06.337+09:00 [WARN] Source /system/test3.txt was changed in the middle of the transfer; initial size was 5084 but 5168 bytes were read
2025-02-24T09:39:06.339+09:00 [NOTICE] Transferred file /system/test3.txt, 5084 bytes
2025-02-24T09:39:06.356+09:00 [NOTICE] Transferred file /system/test2.txt, 5 bytes
2025-02-24T09:39:06.371+09:00 [NOTICE] Transferred file /system/test.txt, 13 bytes
2025-02-24T09:40:33.868+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-24T09:40:33.869+09:00 [NOTICE] Transferred file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-24T09:40:33.916+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-24T09:40:33.982+09:00 [NOTICE] Transferred directory metadata /system
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified directory /system
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified file /system/test.txt, 13 bytes
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified file /system/test2.txt, 5 bytes
2025-02-24T09:40:34.451+09:00 [NOTICE] Verified file /system/test3.txt, 5168 bytes
2025-02-24T09:40:34.470+09:00 [INFO] Execution exec-0706ec578bbf0129d finished with status Success.

はい、検証に成功しているようです。

数回試しましたが、いずれも同じ結果になりました。

やはり、データの検証がONLY_FILES_TRANSFERREDで、転送完了後に転送元ファイルが更新された場合は、転送元と転送先ファイルのズレには気づけないことが分かりました。

転送元でファイルを1秒間隔で更新しながらDataSyncタスクを実行 × POINT_IN_TIME_CONSISTENT

それでは、転送完了後に転送元ロケーションと転送先ロケーションの全てのメタデータのチェックサムの計算をするPOINT_IN_TIME_CONSISTENTの場合はどうでしょうか。

以下のように全体をスキャンするのであれば、転送元ロケーションのファイルのチェックサムの再計算を行ってくれそうです。

POINT_IN_TIME_CONSISTENT: 転送の最後に、 DataSync転送元と転送先全体をスキャンして、両方の場所が完全に同期されていることを確認します。

Options - AWS DataSync

先ほどと同じように以下のように1秒間隔で転送元ロケーションのファイルを更新し続けます。

while ($true) {
    Get-Date -Format "yyyy-MM-dd HH:mm:ss" | Out-File -Append "C:\system\test3.txt"
    Start-Sleep -Seconds 1
}

また、転送先ロケーション上のファイルは全て削除しておきました。

この状態でDataSyncタスク実行時に検証方法をVerify all data (POINT_IN_TIME_CONSISTENT)に変更します。

26.Verify all data.png

DataSyncタスク実行中のtest3.txtの状態を確認します。

27.転送中.png

転送元と転送先でファイルに記載されている内容に差がありますね。

全てのファイル転送完了後の状態は以下のとおりです。転送先のファイルの修正は行われていません。

28.転送完了後.png

DataSyncタスクの実行ステテータスを確認すると、Transfer and verification completed. Verification detected mismatches. See a list of files with mismatches in CloudWatch logs. If no files are listed in CloudWatch logs, contact AWS Support.とエラーになっていました。

29.転送完了後DataSync.png

CloudWatch Logsに出力されたログは以下のとおりです。

2025-02-24T09:44:49.271+09:00 [INFO] Request to start task-00600a02964ae7f2e.
2025-02-24T09:46:42.849+09:00 [NOTICE] Network bandwidth limit enabled for exec-05dfe62094d18c86d at 8.4e-05 Gbps (0 MiB/s)
2025-02-24T09:46:42.849+09:00 [INFO] Execution exec-05dfe62094d18c86d started.
2025-02-24T09:47:07.900+09:00 [INFO] Started logging in destination hostId: host-0ea0a53a9124b025b for Execution exec-05dfe62094d18c86d
2025-02-24T09:47:09.094+09:00 [WARN] Source /system/test3.txt was changed in the middle of the transfer; initial size was 15794 but 15836 bytes were read
2025-02-24T09:47:09.114+09:00 [NOTICE] Transferred file /system/test3.txt, 15794 bytes
2025-02-24T09:47:09.114+09:00 [NOTICE] Transferred file /system/test.txt, 13 bytes
2025-02-24T09:47:09.594+09:00 [NOTICE] Transferred file /system/test2.txt, 5 bytes
2025-02-24T09:48:36.739+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-24T09:48:36.817+09:00 [NOTICE] Transferred file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-24T09:48:36.826+09:00 [NOTICE] Transferred file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-24T09:48:36.894+09:00 [NOTICE] Transferred directory metadata /system
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified directory /
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified directory /system
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified file /system/ASCII_64MiB.txt, 67108864 bytes
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified file /system/ASCII_64MiB_2.txt, 67108864 bytes
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified file /system/ASCII_64MiB_3.txt, 67108864 bytes
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified file /system/test.txt, 13 bytes
2025-02-24T09:48:38.972+09:00 [NOTICE] Verified file /system/test2.txt, 5 bytes
2025-02-24T09:48:38.972+09:00 [NOTICE] Verification failed <> /system/test3.txt
2025-02-24T09:48:38.972+09:00 [NOTICE] /system/test3.txt srcMeta: type=R mode=0755 uid=65534 gid=65534 size=19574 atime=1740358118/34508900 mtime=1740358118/34508900 extAttrsHash=2116514550
2025-02-24T09:48:38.972+09:00 [NOTICE] srcHash: 1509cc28b912a20c7a820b530a603607265c2ee3d2bbb7b0deb561d36686964c
2025-02-24T09:48:38.972+09:00 [NOTICE] /system/test3.txt dstMeta: type=R mode=0755 uid=65534 gid=65534 size=15836 atime=1740358057/108273000 mtime=1740358027/459624300 extAttrsHash=2116514550
2025-02-24T09:48:38.972+09:00 [NOTICE] dstHash: b45b3e568c9383ea4720f159b83040e8567ac525f9d04a4422cb8289c7ffa8e0
2025-02-24T09:48:38.972+09:00 [ERROR] Verification failed: Sync verification failed due to a difference in content of one or more files
2025-02-24T09:48:38.979+09:00 [INFO] Execution exec-05dfe62094d18c86d finished with status Transfer and verification completed. Verification detected mismatches. See a list of files with mismatches in CloudWatch logs. If no files are listed in CloudWatch logs, contact AWS Support..

はい、1秒間隔で更新していた転送先ロケーションのファイルtest3.txtの検証に失敗していることが分かります。

ということで、データの検証がPOINT_IN_TIME_CONSISTENTの場合は、転送完了後に転送元ファイルが更新された場合は、転送元と転送先ファイルのズレには気づけることが分かりました。

やはり、全てのファイルの転送完了後に転送元と転送先を再度スキャンしてメタデータのチェックサムの再計算を行うのでしょう。

ファイルサーバー移行時の最終差分同期のタイミングでは、POINT_IN_TIME_CONSISTENTを使用するのが良さそうですね。

ONLY_FILES_TRANSFERREDでは転送元ロケーションのメタデータのチェックサムの再計算が行われないため、最終差分同期時はPOINT_IN_TIME_CONSISTENTを使用しよう

AWS DataSyncの検証で使用するチェックサムの計算タイミングを確認してみました。

結論、ONLY_FILES_TRANSFERREDでは転送元ロケーションのメタデータのチェックサムの再計算が行われません。

ファイルサーバー移行の最終差分同期時など、確かに同期されていることの確証が欲しい場合はPOINT_IN_TIME_CONSISTENTを使用すると良さそうです。

もちろん、最終差分同期をするタイミングで送信元ロケーションで更新が行われないことが望ましいです。その場合は送信元ロケーションでDataSyncエージェントからのアクセスのみ許可するようにファイアウォールで絞ってあげると良いでしょう。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.