1,067
edits
Changes
Jump to navigation
Jump to search
mLine 1:
Line 1: − + + + − + Line 21:
Line 23: − + Line 32:
Line 34: + + + + + + + − 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.+ + + + + +
→See also: add Memory images deduplication link
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
{{FIXME|describe why incr. dumps are needed, and when to use pre-dump ([[iterative migration]]) instead of incr. dumps.}}
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 ==
# mkdir <path-to-images>/1/
# mkdir -p <path-to-images>/1/
# criu dump --tree <pid> --images-dir <path-to-images>/1/ --leave-running --track-mem
# criu dump --tree <pid> --images-dir <path-to-images>/1/ --leave-running --track-mem
# mkdir <path-to-images>/N/
# mkdir <path-to-images>/N/
# criu dump --tree <pid> --images-dir <path-to-images>/N/ --prev-images-dir ../N-1/
# criu dump --tree <pid> --images-dir <path-to-images>/N/ --track-mem --prev-images-dir ../N-1/
* No <code>--leave-running</code> option will make tasks be killed after dump;
* No <code>--leave-running</code> option will make tasks be killed after dump;
# criu restore --images-dir <path-to-images>/ANY/
# criu restore --images-dir <path-to-images>/ANY/
{{Note|After each (but the last) dump tasks continue running and thus can modify filesystem. CRIU does not snapshot filesystem and assumes, that proper filesystem state for restore is provided by a user.}}
== Data deduplication ==
See [[memory images deduplication]].
== See also ==
* [[Live migration]]
* [[Disk-less migration]]
* [[Iterative migration]]
* [[Memory images deduplication]]
* [[Page server]]
[[Category:HOWTO]]
[[Category:HOWTO]]
[[Category:Memory]]