dgraph-io/dgraph · error

no backup manifests found at location

Error message

no backup manifests found at location %s

What it means

Returned by handleRestoreProposal (worker/online_restore.go:265). Manifests were fetched but after filtering to [IncrementalFrom, BackupNum] the list is empty, so there is nothing to restore at req.Location. It means the backup set at that location does not intersect the requested backup number range.

Solutions

1. List the manifests at the location and set backupNum/incrementalFrom to values present there (or omit them to restore everything).
2. Ensure the location includes the full backup plus all incrementals to restore; always restore from the backup-set root folder.
3. If the desired backup range is missing, re-run dgraph backup to regenerate a complete set before restoring.

Example fix

// before
{"location": "s3://bucket/backups", "backupNum": 9, "incrementalFrom": 7}  // only backups 1-3 exist
// after
{"location": "s3://bucket/backups"}  // restore all, or use existing numbers
{"location": "s3://bucket/backups", "backupNum": 3}

// Check that requested backup numbers exist in the backup set
// (list manifests first; restore with numbers <= highest available)
if requestedBackupNum > highestManifestBackupNum {
    return errors.New("backupNum not present in backup set")
}

When it happens

Trigger: Restore request with backupNum/incrementalFrom values that don't match any backup at the location (e.g. BackupNum=5 but only 3 backups exist); restoring incremental backups without their full backup in the same location; pointing at a folder containing only data files, no manifests.

Common situations: Pointing restore at a partial copy of the backup folder where the full backup manifest was excluded; incrementalFrom/backupNum mistyped; restoring only incremental backups into a fresh cluster; location pointing to a subfolder of a single backup rather than the backup-set root.

Related errors

• cannot parse backup location
• another restore operation is already running
• backup manifest does not contain information for group ID
• br.Close
• cannot assign tablet for pred

AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/ec972767d34c9917. Report an issue: GitHub.

Appendix: source

Thrown at worker/online_restore.go:265

	manifests, err := getManifestsToRestore(handler, uri, req)
	if err != nil {
		return errors.Wrapf(err, "cannot get backup manifests")
	}

	// filter manifests that needs to be restored
	mfsToRestore := manifests[:0]
	for _, m := range manifests {
		if (req.BackupNum == 0 || m.BackupNum <= req.BackupNum) &&
			(req.IncrementalFrom == 0 || m.BackupNum >= req.IncrementalFrom) {

			mfsToRestore = append(mfsToRestore, m)
		}
	}
	manifests = mfsToRestore

	if len(manifests) == 0 {
		return errors.Errorf("no backup manifests found at location %s", req.Location)
	}

	lastManifest := manifests[0]
	restorePreds, ok := lastManifest.Groups[req.GroupId]
	if !ok {
		return errors.Errorf("backup manifest does not contain information for group ID %d", req.GroupId)
	}

	// When we change predicate names from {fromNamespace}-predicate to 0-predicate,
	// this is not straight forward. This is because, Zero has a knowledge of what
	// predicate belongs to what group. We need to ensure that while transforming predicate names,
	// we let the Zero know. The algorithm that we follow here is that,
	// the group that had the data at the time of backup, has the data after restore.
	// For example, if we restore namespace 1 and 1-email belongs to group 1, after restore,
	// 0-email would belong to group 1 as well.

	// There are two types of predicates in a namespace:

View on GitHub (pinned to 759e242be6)