Moving storage results in "No previous backup found" and complete reprocessing of repository

david3 · 10 January 2025 16:39

I’ve seen this behavior previously, but I’m curious as to why it happens.

I relocated the local storage pool (local USB drive) from the NAS (repository host) to another server. Using the web GUI, I created a new storage at the new location. I then ran a Check operation to confirm that Duplicacy could read the existing snapshots. First time through, Check did not list the snapshots. I had to adjust file permissions and rerun the Check job. 2nd time - sucess.

Next, I started a backup job. Duplicacy appears to be reading/processing EVERY file in the repository and then finding/confirming that the vast majority are already chunked and available in the storage pool. The repository is 7TB and this complete rediscovery is taking over 24 hours. The following message was posted in the log: “BACKUP_START No previous backup found”.

Did I miss a step? Or is there some way to avoid having Duplicacy start from scratch like this?

saspus · 10 January 2025 17:28

This message is printed here:

github.com

gilbertchen/duplicacy/blob/065ae50868574404c502fb8b9508a2475d218337/src/duplicacy_backupmanager.go#L161

    
      
          
          
	if manager.config.rsaPublicKey != nil && len(manager.config.FileKey) > 0 {
          		LOG_INFO("BACKUP_KEY", "RSA encryption is enabled")
          	}
          
          
	if manager.excludeByAttribute {
          		LOG_INFO("BACKUP_EXCLUDE", "Exclude files with no-backup attributes")
          	}
          
          
	remoteSnapshot := manager.SnapshotManager.downloadLatestSnapshot(manager.snapshotID)
          	if remoteSnapshot == nil {
          		LOG_INFO("BACKUP_START", "No previous backup found")
          		remoteSnapshot = CreateEmptySnapshot(manager.snapshotID)
          	} else {
          		LOG_INFO("BACKUP_START", "Last backup at revision %d found", remoteSnapshot.Revision)
          	}
          
          
	hashMode := remoteSnapshot.Revision == 0 || !quickMode
          
          
	// This cache contains all chunks referenced by last snasphot. Any other chunks will lead to a call to
          	// UploadChunk.

I would verify permissions on the snapshot files. Make sure the user duplicacy is accessing the target storage on behalf of can not only list files, but also read data.

david3 · 10 January 2025 19:03

Resolved. It was actually a config issue on my part.

When I set up the new “Backup” in the GUI, I assigned it a new backup ID to avoid conflict with the old backup config. I had forgotten that Duplicacy would use this to create a brand-new set of snapshots in the relocated storage even though the repository “target” was the same. Therefore, the program would not see any existing snaps and proceeded to perform a “from scratch” backup using the new ID—even though the vast majority of chunks were already stored and available.

I attempted to fix this by editing the duplicacy.json file but kept changing something Duplicacy didn’t like. I eventually returned to the GUI, deleted both IDs, and started over.

All good now.