原文来自CRIU官网的文章：
翻译此文，用于学习CRIU的dump和pre-dump机制。翻译时没有用翻译软件，不求字字准确，能表达出核心含义，语句通顺就行。甚至会按照我对CRIU的研究拓展一下。
本文作者按个人理解加以描述的文字用（__）来标记。

本页描述了如何通过使用内存变化跟踪能力（）来执行预复制内存迁移（），从而减少应用程序的冻结时间。 :::warning 注意：假设你在这篇文章之前已经阅读了《》这篇文章。 :::

迁移顺序

下面介绍的步骤看起来就像常规的热迁移，但是在其中会穿插着一次或更多的叫做pre-dump的阶段。

pre-dump

将你要热迁移的应用程序pre-dump到一个位置。和常规的dump之后会干掉程序不同，应用程序在pre-dump之后会继续运行。
命令如下

criu pre-dump --tree <pid> --images-dir <path-to-existing-directory-A>

存放pre-dump生成的image的目录可以放在一个共享存储上，或者也可以用无磁盘迁移（）来避免复制步骤。
现在你可以接着pre-dump，也可以进行常规的dump操作。下一次pre-dump操作将会产生另一个image数据集，这个数据集“仅会包含和上一个pre-dump之后变化了的内存页”，在经历几次pre-dump迭代之后，可以大量减少dump的数据量，以至于减少程序冻结的时间。
请注意，如果你要执行大于一次pre-dump的步骤，你应该要创建不一样的目录用于pre-dump存放image文件。并且还要注意在下发pre-dump和dump命令时正确使用—images-dir和-prev-images-dir这两个选项。

dump

现在，你可以正常dump你的进程了。
在源端执行以下命令。

criu dump --tree <pid> --images-dir <path-to-existing-directory-B> --prev-images-dir <path-to-directory-A-relative-to-B> --leave-stopped --track-mem

注意两点：

1. 这一次dump会比没有用pre-dump要快，因为他要dump的内存，只有最后一次pre-dump到现在这一时间段中变化的内存页。
2. —prev-images-dir选项为之前pre-dump后存放image的目录。—images-dir为这次dump后存放image的目录。

   copy

   在源端，用下面的命令拷贝image

   scp -r <path-to-images-dir> <dst>:/<path-to-images>

   或者用rsync

   rsync -rl <path-to-images-dir>/ <dst>:<path-to-images>

   注意：启用 “将符号链接复制为符号链接”（rsync为-l），以确保符号链接在之前的目录之间被保留，这很重要。当-r被传递给scp时，它会遵循在树形遍历中遇到的符号链接。（也就是我们所说的快捷方式指向的目录要保留，而不是保留指向的文件）

   restore

   在目标节点上，执行命令，从image中恢复应用程序。

   criu restore --images-dir <path-to-images>

   kill

   如果一切顺利就可以干掉源节点上停止的任务。

   FIXME put command here

   这里应该是dump之后程序是被冻结而不是被干掉。要手动干掉程序才行。

   扩展阅读

• P.Haul is the Go extension to CRIU doing live migration