Difference between revisions of "Incremental dumps"
Jump to navigation
Jump to search
(Created page with "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 <...") |
m (→See also: add Memory images deduplication link) |
||
| (16 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | If you're doing several dumps in a row | + | {{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 | ||
| Line 21: | Line 23: | ||
# 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; | ||
| Line 31: | Line 33: | ||
# 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]] | ||
Latest revision as of 04:21, 31 August 2016
|
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[edit]
# 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[edit]
# 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[edit]
# mkdir <path-to-images>/N/ # criu dump --tree <pid> --images-dir <path-to-images>/N/ --track-mem --prev-images-dir ../N-1/
- No
--leave-runningoption will make tasks be killed after dump; - No need in memory tracking option.
Restore[edit]
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 does not snapshot filesystem and assumes, that proper filesystem state for restore is provided by a user. |
Data deduplication[edit]
See memory images deduplication.