dgraph-io/dgraph · error

while retrieving manifests

Error message

while retrieving manifests

What it means

During an online restore, verifyRequest calls getManifestsToRestore to list and read backup manifest objects from the backup location (URI handler). Any error opening, listing, or decoding those manifests is wrapped as "while retrieving manifests". This indicates the backup storage could not be read or the manifests are missing/corrupt, so restore verification aborts.

Source

Thrown at worker/online_restore.go:43

	"github.com/dgraph-io/badger/v4/options"
	"github.com/dgraph-io/dgraph/v25/conn"
	"github.com/dgraph-io/dgraph/v25/posting"
	"github.com/dgraph-io/dgraph/v25/protos/pb"
	"github.com/dgraph-io/dgraph/v25/schema"
	"github.com/dgraph-io/dgraph/v25/tok/hnsw"
	"github.com/dgraph-io/dgraph/v25/x"
)

const (
	errRestoreProposal = "cannot propose restore request"
)

// verifyRequest verifies that the manifest satisfies the requirements to process the given
// restore request.
func verifyRequest(h UriHandler, uri *url.URL, req *pb.RestoreRequest, currentGroups []uint32) error {
	manifests, err := getManifestsToRestore(h, uri, req)
	if err != nil {
		return errors.Wrapf(err, "while retrieving manifests")
	}
	if len(manifests) == 0 {
		return errors.Errorf("No backups with the specified backup ID %s", req.GetBackupId())
	}

	// TODO(Ahsan): Do we need to verify the manifests again here?
	if err := verifyManifests(manifests); err != nil {
		return err
	}

	lastManifest := manifests[0]
	if len(currentGroups) != len(lastManifest.Groups) {
		return errors.Errorf("groups in cluster and latest backup manifest differ")
	}

	for _, group := range currentGroups {
		if _, ok := lastManifest.Groups[group]; !ok {
			return errors.Errorf("groups in cluster and latest backup manifest differ")

View on GitHub (pinned to 759e242be6)

Solutions

1. Verify the backup URI and credentials: test listing the bucket/prefix with the same tooling (aws s3 ls / mc ls) used in the URI
2. Confirm the backup ID matches an existing backup under that URI and that manifest objects (manifest.json files) exist and are readable
3. Check Alpha logs for the underlying wrapped error (e.g. access denied, no such bucket, connection refused) and fix storage access/networking

Example fix

// before
GRAPHICS URI: dgraph restore -x s3://wrong-bucket/backups -b backup-2024
// after
dgraph restore -x s3://correct-bucket/dgraph -b backup-2024  # verify with aws s3 ls first

// before restore: verify manifests are listable
h := urfavecliHandler // your UriHandler
u, _ := url.Parse(backupUri)
if _, err := h.List(u); err != nil {
    return fmt.Errorf("backup location unreachable: %w", err)
}

if err := verifyRequest(h, uri, req, groups); err != nil {
    if strings.Contains(err.Error(), "while retrieving manifests") {
        log.Printf("check backup URI %s, credentials, and backup ID %s: %v", uri, req.BackupId, err)
    }
    return err
}

When it happens

Trigger: Calling VerifyBackup (or restore) where the backup URI is wrong or credentials are missing, the object store is unreachable, no objects exist under the backup ID (or manifest objects are unreadable/corrupt), causing getManifestsToRestore to fail and the error to be wrapped.

Common situations: Misconfigured s3/minio credentials or bucket name in the backup URL; network/firewall blocking access to object storage; backups deleted or overwritten; restoring from a partially completed backup; using the wrong backup ID or path prefix.

Related errors

• cannot retrieve manifests
• newBackupReader
• br.Close
• while copying value
• expected a BackupNum value of 1 for first manifest but got %

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