« Previous 1 2 3 Next »
Save and Restore Linux Processes with CRIU
On Ice
Reanimation
To wake up a stored process, use the command:
criu restore -D ~/checkpoint --restore-detached
The --restore-detached
parameter ensures that CRIU terminates after the restore. The reanimated process then has init as its parent process and keeps the same process ID as before the freeze. If this PID has been reassigned in the meantime, the restore quits with an error. You can remedy this using the --namespaces
or -n
option, which means the task is assigned a new PID by the system and only retains its old ID internally in a virtual process namespace.
If you backed up the process using --shell-job
, this same parameter is mandatory for the restore (Figure 6). The process then starts up in the shell in which you called criu
. Under certain circumstances, it takes a moment for the process to actually start working.
When you restore, the backup remains in the checkpoint
directory. You can thus revive the process in the same place at any time.
To wake up the stored process on another system, you copy the complete directory with the backup to the other computer and revive the process there with criu restore
. However, the new environment must match the old one and contain the necessary files in the same directory paths. Ideally, the new system will be a clone. Another option is to use a distributed filesystem such as NFS to provide the files. In any case, administrators should run through live migrations for test purposes to find missing libraries, configuration files, and documents and put them in place.
Looking Ahead
CRIU lets you prepare a backup process then accelerate it with the pre-dump
parameter:
criu pre-dump -t 2369 -D ~/checkpoint/pre
Processes continue to run normally after this step. A new call to the command at any time updates the backup (Figure 7) by pointing to the pre-dump with the --prev-images-dir
parameter,
criu dump -t 2369 -D ~/checkpoint/dump --prev-images-dir ../pre
which expects a path relative to the directory specified by -D
. In the example above, the pre-dump output ends up in ~/checkpoint/pre
, with the dump in ~/checkpoint/dump
. Restoring with
criu restore -D ~/checkpoint/dump --restore-detached
works like any other restore command.
Thrifty Repetition
If you want create multiple snapshots for a process, you can save time and storage space with an incremental backup. To do this, first create a dump as usual, but leave the process running with the --leave-running
parameter:
criu dump -t 2334 -D ~/checkpoint/1/ --leave-running --track-mem
The first backup ends up in the ~/checkpoint/1/
directory. Thanks to the --track-mem
parameter, CRIU can tell the kernel to watch the main memory area of the process. A second dump accelerates its information:
criu dump -t 2334 -D ~/checkpoint/2/ --leave-running --track-mem \ --prev-images-dir ../1/
In this example, --prev-images-dir
reveals the location of the first backup, again creating the directory relative to the path defined by -D
. Following the same principle, you then create additional backups. For the last dump, abandoning the --leave-running
and --track-mem
parameters terminates the process. The subsequent recovery is the same as before:
criu restore -D ~/checkpoint/2/ --restore-detached
A directory normally contains a complete backup. On request, CRIU saves space by storing only the changes that happened since the last dump. This is the task of the deduplication feature, which you call with the --auto-dedup
parameter:
criu dump -t 2334 -D ~/checkpoint/2/ --leave-running --track-mem \ --prev-images-dir ../1/ --auto-dedup
CRIU will now delete all unnecessary data in the previous backup, but not in the new one, so you now have a complete dump in ~/checkpoint/2
; ~/checkpoint/1
only keeps the delta to the second backup. If you already have incremental backups, the dedup
action,
criu dedup -D ~/checkpoint/2/
retroactively reduces them to the delta.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)