What causes "file does not exist for table %d" in dgraph-io/badger?

Restore the missing table files from a backup so the directory matches the manifest

file does not exist for table %d

Error message

file does not exist for table %d

What it means

During DB recovery, revertToManifest cross-checks the MANIFEST file against the actual table files in the directory. If the manifest references a table ID that no longer exists on disk, badger refuses to silently drop it and returns this error, because proceeding could lose committed data.

Source

Thrown at levels.go:51

type levelsController struct {
	nextFileID atomic.Uint64
	l0stallsMs atomic.Int64

	// The following are initialized once and const.
	levels []*levelHandler
	kv     *DB

	cstatus compactStatus
}

// revertToManifest checks that all necessary table files exist and removes all table files not
// referenced by the manifest. idMap is a set of table file id's that were read from the directory
// listing.
func revertToManifest(kv *DB, mf *Manifest, idMap map[uint64]struct{}) error {
	// 1. Check all files in manifest exist.
	for id := range mf.Tables {
		if _, ok := idMap[id]; !ok {
			return fmt.Errorf("file does not exist for table %d", id)
		}
	}

	// 2. Delete files that shouldn't exist.
	for id := range idMap {
		if _, ok := mf.Tables[id]; !ok {
			kv.opt.Debugf("Table file %d not referenced in MANIFEST\n", id)
			filename := table.NewFilename(id, kv.opt.Dir)
			if err := os.Remove(filename); err != nil {
				return y.Wrapf(err, "While removing table %d", id)
			}
		}
	}

	return nil
}

func newLevelsController(db *DB, mf *Manifest) (*levelsController, error) {

View on GitHub (pinned to 2a001d466f)

Solutions

Restore the missing table files from a backup so the directory matches the manifest
If data loss is acceptable, back up the directory and repair the MANIFEST (remove the dangling table entries) or start from the last good backup
Never mix files from two different DB directories; copy the whole directory atomically
Run badger info on the directory to see which files/manifest entries are inconsistent

Example fix

# before: directory missing 003.sst referenced by MANIFEST -> open fails
# after: restore full directory from backup
aws s3 cp s3://my-backup/badger/ ./data/badger/ --recursive  # ensure ALL .sst files restored
badger info --dir ./data/badger  # verify consistency before opening

Defensive patterns

Strategy: validation

Validate before calling

# shell: verify directory consistency before opening
badger info --dir ./data/badger
ls ./data/badger/*.sst | wc -l  # compare against manifest table count

Try / catch

// Go
db, err := badger.Open(opts)
if err != nil && strings.Contains(err.Error(), "file does not exist for table") {
    // stop and restore from backup; do not delete files blindly
    return fmt.Errorf("corrupt/incomplete badger dir: %w", err)
}

Prevention

Copy badger directories only while the DB is closed, and copy everything (MANIFEST + all .sst/.vlog)
Take atomic snapshots/backups
Never delete .sst files manually to free space
Run badger info after restore and before open

When it happens

Trigger: Opening a badger DB whose directory is missing SSTable files listed in MANIFEST — e.g. someone deleted *.vlog/*.sst files, copied only part of the directory, or a crash left the manifest ahead of the files.

Common situations: Incomplete backup/restore of the badger directory; manually cleaning up disk space by deleting table files; filesystem corruption or interrupted copy; running against a directory restored with rsync excluding some files.

Related errors

AI-assisted analysis of dgraph-io/badger@2a001d466f (2026-09-05). Data as JSON: /api/errors/9fd4a8f61ce26b71. Report an issue: GitHub.