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.

Figure 6: Restoring a process backed up with, but restored without, --shell-job fails without stating the reason.

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,

Figure 7: A preliminary backup with pre-dump speeds up the storage process.

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,