Difference between revisions of "Incremental dumps"

From CRIU
Jump to navigation Jump to search
m
Line 1: Line 1:
If you're doing several dumps in a row, the 2nd and subsequent dumps can be speed up. Here's how:
+
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 ==
 
== Create the first dump ==

Revision as of 20:30, 2 December 2013

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;
  • The --leave-running option is used to make criu not kill the tasks after dump, but let them run further;
  • The --track-mem option 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-dir path is relative to the --images-dir one;
  • 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-running option 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.svg 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