Hello
For some time now, I’ve noticed that my incremental backup is taking a very long time, and ultimately contains only a small amount of data (30GB).
It takes several hours to scan all the files.
Is this normal?
I think it used to be very fast.
il there a problem ?
How avoid to scan every files ?
I believe this issue occurred after migrating data from the NAS client.
I moved data from two drives to a single drive on the client.
as if it would retransfer all the data every night!!!
| 07/08/25 13:18 | WARNING | Not all folder metadata could be applied. Metadata was inconsistent. |
|---|---|---|
| 07/08/25 13:18 | INFO | Writing new file list… |
| 07/08/25 13:18 | INFO | All metadata was present |
| 07/08/25 13:18 | DEBUG | Syncing file system… |
| 07/08/25 13:18 | DEBUG | Creating symbolic links. -1 |
| 07/08/25 13:18 | DEBUG | Creating symbolic links. -2 |
| 07/08/25 13:18 | DEBUG | Symbolic links created. |
| 07/08/25 13:18 | INFO | Transferred 951.519 GB - Average speed: 490.065 MBit/s |
| 07/08/25 13:18 | DEBUG | Script does not exist urbackup/post_incr_filebackup |
| 07/08/25 13:18 | INFO | Time taken for backing up client nas: 6h 33m 15s |
| 07/08/25 13:18 | INFO | Backup succeeded |
You have a warning that the meta data is inconsistent. How did you migrate the data to ensure the file meta data was preserved?
thanks for answer
I did not migrate data/backups from Urbackup only the office source data files
I simply migrated the data to other disks with Rsync.
On the urbackup side, I simply deleted and re-added the locations with urbackupclientctl add-backupdir
PATH NAME FLAGS
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/BACKUPS-INFRA BACKUP-INFRA follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/Documents Documents follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/ADAM ADAM follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/LISA LISA follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/DATASTORE-BACKUP DATASTORE-BACKUP follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/photos PHOTOS follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/Pascaline-synchro Pascaline-synchro follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/raspberry RASPBERRY follow_symlinks,symlinks_optional,share_hashes
/srv/dev-disk-by-uuid-6aff55d4-e53a-4979-87c2-945c6552bdda/NAS/DOCKER DOCKER follow_symlinks,symlinks_optional,share_hashes
IIRC the path name is part of the meta data and its stored in the db. It looks like you have changed the meta data by using the new disk uuid in the path.
Ok thanks.
It’s not very intuitive.
I deleted all the backupdirs and added the new ones with the addbackupdir command; it should have updated the metadata accordingly…
I don’t see what I could have done that was cleaner…
What’s the solution?
Delete all the backupdirs, delete the client, and recreate it???
It’s very cumbersome.
I don’t know - it depends how urbackup deals with the state change between client and server. I would have thought after the first new backup things would have settled down. Maybe someone else can help.
