Gitpod Snapshotting: Uncertain Timing of Filesystem Sync During Workspace Restart

Snapshot Behavior

Gitpod snapshots operate at the persistent volume layer, not the container memory layer. When a snapshot is requested, the platform captures the volume state as it exists at that instant, typically via a Kubernetes CSI snapshot mechanism. However, the operating system inside the workspace may have dirty pages in the page cache, and applications may hold data in memory buffers that have not been written back to disk. Gitpod does not publicly document a guaranteed flush of all such buffers before the snapshot is taken, and no published SLA or consistency model covers in-memory state at snapshot time.

Likely Explanation

The snapshot mechanism, implemented at the block-device level, records whatever blocks are valid on the underlying storage when the snapshot call completes. If the OS or application has not yet flushed dirty pages through sync, fdatasync, or explicit checkpointing, those changes will not be part of the captured volume state. This is a fundamental limitation of block-level snapshots, not a Gitpod-specific behavior, though the platform could mitigate it by prompting a sync or providing a pre-snapshot hook.

Confirmed Facts

• Gitpod's documentation states snapshots are intended for backup/restore and prebuild acceleration, not for point-in-time consistency of running application state.
• The gp snapshot CLI initiates the snapshot asynchronously; there is no synchronous wait-for-completion endpoint or status API that confirms the snapshot has fully materialized on the storage backend.
• Gitpod does not expose a public API or CLI command to programmatically verify that a restored workspace matches the snapshot's contents.
• For uncommitted Git changes, the only reliable verification route is user-defined checks after workspace restart (e.g., git status --porcelain, file checksums, application-level integrity checks).

Steps Needed

1. If your workspace contains data that must survive a snapshot restore, execute sync inside the container and, where applicable, trigger a database or application checkpoint (e.g., sqlite3 PRAGMA wal_checkpoint or editor auto-save) before initiating the snapshot via the Gitpod UI or gp snapshot command.
2. After restoring from the snapshot, verify critical files with sha256sum or git diff against the expected state.
3. Repeat the test with and without an explicit sync to observe the practical difference in capture timing.

Diagnostic Detail Needed

Have you run sync inside the container and explicitly triggered a snapshot afterward, then compared file presence and content after restore? Confirming this will determine whether the recommendation shifts from "assume data may be lost without explicit sync" to "if sync is performed, recent writes are reliably captured."