If you're doing several dumps in a row, the 2nd and subsequent dumps can be sped up. Here'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;
--leave-runningoption is used to make criu not kill the tasks after dump, but let them run further;
--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
- 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/
--leave-runningoption will make tasks be killed after dump;
- No need in memory tracking option.
Now you can restore the processes from whatever images you want
# criu restore --images-dir <path-to-images>/ANY/
|Note: 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|
After creation of such stack of images some data would get duplication in dumps. If you don't want to keep duplicates there's an ability to punch duplicate data from non-top images. There are two options for this.
- Deduplication action
crui dedupcommand would open the image directory and punch holes in the parent images in needed places
- Automatic deduplication while dumping
--auto-dedupoption would cause every write to images with process' pages to go an punch holes in respective parent images.
The latter option appies to both
page-server actions and thus is extremely useful in disk-less migration scenario.