Versioning database

[markb]

I run a backup to s3 and the versioning folder keeps growing. 35000 files and 95Gb. (No delta)

This enormously slows down the fast backup profile.

Why creating a fast backup profile function and refusing to create a versioning database to eliminate this rescan inefficiency that renders cloud backups almost useless?

Why not assuming that no one will touch the versioning files (and leave the responsibility to the user not to touch them) and storing everything in a database?

If the reason for no db = a problem with the version restore function handled by syncback..
Then give users a choice at least to create versions with a db, giving only a manual restore option:

1. build a database and let the versioning execute without scanning
2. Disable the versioning restore function (just create the versions and leave it to the sysadmin to manually restore them in case it's needed)

Even this half working workaround would be better of what I have to do now (which is executing a lambda function to move the $sbv folder periodically to another bucket to allow the scan to take a reasonable time, which is ridiculous in my opinion)


Thanks

[MikeTaku]

Why doesn't SyncBack use a versioning database to speed up backups instead of rescanning all versioned files?