Process Hibernation: Difference between revisions
(Created page with "MemCP is a In-Memory database. In case you use the <code>memory</code> engine, there is no data stored on disk. <code>criu</code> is an OpenSource project to hibernate processes on linux on disk and restore them later (see https://criu.org/Main_Page). You can hibernate the memcp process with sudo criu dump -t [PID] -j -D [DUMP_DIRECTORY] And reactivate the process with: sudo criu restore -j -D [DUMP_DIRECTORY]") |
Wikiservice (talk | contribs) (Refresh MemCP documentation: accuracy, operational guidance, performance profile and maintained API reference) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
<!-- Copyright (C) 2026 Carl-Philip Haensch --> | |||
<!-- SPDX-License-Identifier: GPL-3.0-or-later --> | |||
= Process Hibernation = | |||
Linux CRIU can checkpoint and restore a complete process, including RAM-only state. This makes it interesting for development experiments with <code>memory</code> tables, but it is not MemCP's supported durability, backup or upgrade mechanism. Open sockets, kernel features, file descriptors, JIT mappings and external storage connections can make restoration fail or restore an unsafe environment. | |||
An experimental local workflow is: | |||
<pre>sudo criu dump -t PID -j -D DUMP_DIRECTORY | |||
sudo criu restore -j -D DUMP_DIRECTORY</pre> | |||
Stop incoming traffic and test the exact kernel, CRIU and MemCP build before relying on this even temporarily. A checkpoint is tied to its host/runtime environment and does not replace a portable data backup. Persistent production data should use <code>ENGINE=safe</code> and tested storage-level backup/restore procedures. | |||
See [[Persistency and Performance Guarantees]], [[File System]] and [[Deployment]]. | |||
Latest revision as of 12:14, 28 August 2026
Process Hibernation
Linux CRIU can checkpoint and restore a complete process, including RAM-only state. This makes it interesting for development experiments with memory tables, but it is not MemCP's supported durability, backup or upgrade mechanism. Open sockets, kernel features, file descriptors, JIT mappings and external storage connections can make restoration fail or restore an unsafe environment.
An experimental local workflow is:
sudo criu dump -t PID -j -D DUMP_DIRECTORY sudo criu restore -j -D DUMP_DIRECTORY
Stop incoming traffic and test the exact kernel, CRIU and MemCP build before relying on this even temporarily. A checkpoint is tied to its host/runtime environment and does not replace a portable data backup. Persistent production data should use ENGINE=safe and tested storage-level backup/restore procedures.
See Persistency and Performance Guarantees, File System and Deployment.