apache/cassandra · critical · RuntimeException

Unable to take a snapshot %s on %s.%s

Error message

Unable to take a snapshot %s on %s.%s

What it means

Cassandra's repair prepare phase snapshots the tables involved so the repair operates on a consistent set of sstables. When the async snapshot task throws, the exception is wrapped in this RuntimeException naming the snapshot, keyspace and table. Common causes include disk I/O errors, missing snapshot directory permissions, or an exception inside SnapshotManager's snapshot logic.

Source

Thrown at src/java/org/apache/cassandra/db/repair/CassandraTableRepairManager.java:99

        try
        {
            ActiveRepairService.instance().snapshotExecutor.submit(() -> {
                if (force || !SnapshotManager.instance.exists(cfs.getKeyspaceName(), cfs.getTableName(), name))
                {
                    Predicate<SSTableReader> predicate = sstable -> sstable != null &&
                                                                    !sstable.metadata().isIndex() && // exclude SSTables from 2i
                                                                    new Bounds<>(sstable.getFirst().getToken(), sstable.getLast().getToken()).intersects(ranges);

                    SnapshotOptions options = SnapshotOptions.systemSnapshot(name, SnapshotType.REPAIR, predicate, cfs.getKeyspaceTableName())
                                                             .ephemeral()
                                                             .build();
                    SnapshotManager.instance.takeSnapshot(options);
                }
            }).get();
        }
        catch (Exception ex)
        {
            throw new RuntimeException(String.format("Unable to take a snapshot %s on %s.%s", name, cfs.metadata.keyspace, cfs.metadata.name), ex);
        }

    }
}

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Inspect the cause attached to this RuntimeException (and node.log) for the real snapshot failure reason
2. Free disk space / fix directory permissions for the snapshots directory and retry the repair
3. Verify the table still exists and wasn't concurrently dropped; retry the repair after resolving
4. If SnapshotManager snapshot limit issues, raise or clear limits (nodetool snapshottools / configured max snapshot TTL count)

// pre-checks before repair
System.err.println("df -h"); // ensure adequate disk space
System.err.println("ls -ld /var/lib/cassandra/data/*/snapshots"); // permissions exist

try { repairManager.prepare(state); } catch (RuntimeException e) { if (e.getMessage().startsWith("Unable to take a snapshot")) { log.error("snapshot failed: {}", e.getCause(), e); retryAfterFix(); } else throw e; }

When it happens

Trigger: nodetool repair (or incremental repair) on a keyspace/table where taking the snapshot fails: disk full, I/O error, permission problems on the data/snapshot directories, or a concurrent operation invalidating the snapshot request (e.g. table dropped mid-snapshot).

Common situations: Disk full on a node during repair; read-only or wrong-ownership data directories; table dropped/altered concurrently; SnapshotManager limits exceeded; underlying storage faults.

Related errors

• repair_session_max_tree_depth should not be < 10, but was ${
• repair_session_space must be > 0, but was ${conf.repair_sess
• snapshot_links_per_second must be >= 0
• Could not reference sstables
• Prepare phase failed because it encountered legacy sstables

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/cc8d367e7ad720d6. Report an issue: GitHub.