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) |
||
| 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: | |||
<syntaxhighlight lang="bash">sudo criu dump -t PID -j -D DUMP_DIRECTORY | |||
sudo criu restore -j -D DUMP_DIRECTORY</syntaxhighlight> | |||
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]]. | |||
Revision as of 11:59, 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:
<syntaxhighlight lang="bash">sudo criu dump -t PID -j -D DUMP_DIRECTORY sudo criu restore -j -D DUMP_DIRECTORY</syntaxhighlight>
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.