If you're doing several dumps in a row, one in some time after another, the 2nd and subsequent dumps can be speed-ed up and that's how
Create the first dump
# mkdir -p <path-to-images>/1/ # criu dump --tree <pid> --images-dir <path-to-images>/1/ --leave-running --track-mem
- Images are put into the
1/sub-directory, since we're about to create the 2nd (and more) incremental dumps and it's handy to store them in this way; - The
--leave-runningoption is used to make criu not kill the tasks after dump, but let them run further; - The
--track-memoption makes criu ask kernel to monitor memory changes to optimize the subsequent dump.
Create the second dump
# mkdir <path-to-images>/2/ # criu dump --tree <pid> --images-dir <path-to-images>/2/ --leave-running --track-mem --prev-images-dir ../1/
- Note, that the
--prev-images-dirpath is relative to the--images-dirone; - Similarly the 3rd and all the other dumps can be created.
Create the last dump
# mkdir <path-to-images>/N/ # criu dump --tree <pid> --images-dir <path-to-images>/N/ --prev-images-dir ../N-1/
- No
--leave-runningoption will make tasks be killed after dump; - No need in memory tracking option.
Restore
Now you can restore the processes from whatever images you want
# criu restore --images-dir <path-to-images>/ANY/
Note, that after each (but the last) dump tasks continue running and thus can modify filesystem. CRIU doesn't snapshot filesystem and assumes, that proper filesystem state for restore is provided by user.