Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Cloud Native Ecosystem / Containers

Grab a Snapshot of Your Container Image with Checkpoint

When you start a container from a checkpoint, that container will be in the same state (including memory and processes) it was in when the checkpoint was created.
Mar 11th, 2023 6:00am by
Featued image for: Grab a Snapshot of Your Container Image with Checkpoint
Image via Pixabay.

Have you ever been in a situation where you have a Docker or Podman container running exactly how you need and wished you had the ability to save a snapshot of it, so you can ensure you’ve got a running state saved in case something goes awry with the container? Should disaster strike, you can simply start a new container using the snapshot.

That’d be nice, wouldn’t it?

Well, it’s actually possible, thanks to the checkpoint feature. Consider this feature as a handy way to back up a running container state, so you can use it any time you need. When you start a container from a checkpoint, that container will be in the same state (including memory and processes) it was in when the checkpoint was created. Another really cool feature of checkpoint is that, when you start a new container from a saved state, it will deploy faster than it originally did.


Now, before we continue, know that this is an experimental feature, so use it with caution. I would suggest using it on a non-production machine until you A) get the hang of it and B) you trust it. Until then, consider it only for testing purposes.

With that said, let’s create some checkpoints.

What You’ll Need

To use docker checkpoints, you’ll need a running instance of docker on a Ubuntu Server platform and a user with sudo privileges. That’s it. Let’s get to work.

Installing the Necessary Dependency

The first thing to do is install the lone dependency, Criu, the core Linux checkpoint utility. Log in to your Ubuntu Server instance and add the necessary repository for the software with the command:

Update apt with:

You can now install Criu with the command:

Enabling Experimental Features

Now that you have Criu installed, you’ll need to enable experimental features for Docker. To do this, create a new file with the command:

Add the following three lines to the file:

Save and close the file.

Restart Docker with:

Experimental features have now been enabled.

Deploy a Test Container

Instead of testing this on your currently running containers, let’s deploy a sample NGINX container to use. Deploy that container with the command:

Give the container a moment to spin up. You should be able to access the running container with the command:

Once inside the container, let’s modify the NGINX index.html page. Install the nano editor in the container with the following two commands:

Open index.html for editing with the command:

Change the contents of that file to:

<!doctype html>
<html lang=”en”>
  <meta charset=”utf-8″>
  <title>Checkpoint Test</title>
  <h2>Hello from The New Stack</h2>

Save and close the file. Exit from the container with the exit command and restart the container with:

Create Your First Checkpoint

We’re going to create a checkpoint, while still leaving the NGINX container running, which is achieved with the following command:

You can name the checkpoint anything you like. In this demonstration, I’ve opted for checkpoint00. After you run the command, you’ll see:

The checkpoint was successfully created.

Now, I have run into instances where Docker CE and the checkpoint feature failed to work. On the other hand, I’ve always had success installing the version of Docker that is found in the standard repositories, which can be installed with the command:

Using a Checkpoint

Let’s say you do some work on the NGINX container and it fails on you. Since you’ve created a checkpoint, you can use it. Remember, our checkpoint is named checkpoint00. Let’s spin up a new container, which can be done with the command:

You might be smarter than me and give your checkpoints meaningful names, such as something that indicates the current state or a date. So instead of checkpoint00, you might have checkpoint022323 (for February 23, 2023).

You can verify the checkpoints you’ve created for a particular container. For example, to list all of the checkpoints you’ve created from checkpoint-test, issue the command:

You might see something like this in the output:

But What about Podman?

Podman has a checkpoint feature built into it, but there’s a problem with its usage. The only way to checkpoint a container is to do so with sudo privileges. The catch is that is you deploy a container as a standard user, you can’t checkpoint it with sudo, because podman won’t see the running container (as it was deployed by another user).

However, if you deploy the podman container with root, like so:

You can then checkpoint the container like so:

As you’ve probably expected, doing this defeats the purpose of rootless containers. However, there are rumblings that eventually podman will allow checkpointing with rootless containers. We’ll see what the future holds.

And that’s all there is to using the checkpoint command for both Docker and Podman. Give this a try and see if it doesn’t help you always have a running state for the containers you depend on.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.