Reset the statistics data?

Server
1

Hi to you all !
I’ve made a crude series of mistakes that I could resume like this :

  • Accidentally, I’ve created a symlink to a very big folder that was taken into my backup plan by urbackup server (using container in openmediavault) for this client (physical machine)
  • Since I almost saturated my disk, I’ve proceeded to remove the oldest backups one by one. Better, but far from enough.
  • Then I entered barbarian mode and proceed to :
rm -rf assets/fedora/.directory_pool/*

And recreate a full file backup.
Rudely efficient disk-wise, but obviously not so much from urbackup since I have now my statistics that are still listing some 690 Gb of data when it should now be close to … 95 Gb, top.
Is there something I should/can do about it please ?
Thanks for your help

2

You appear to have deleted the folders common to many backups. Unless you can undelete these files showhow then I don’t see how you can recover the archive. Many folders should still be available so it may be worth hanging onto the archive and starting afresh.

3

Thanks for your answer GilesP but it seems i didn’t make myself clear enough, sorry. I don’t intend to recover anything. My only concern is that since I have deleted the folders I intended to delete, the statistics page is showing old and wrong values, and that’s what I want to reset, or find a way to get it accurate to the real disk space used.

4

What do you think was in the directory pool folder? Try doing a forum search.

5

.directory_pool : holds my deduplicated backup data
And since I’ve deleted that intentionnally without doing anything about the metadata in the database, I understand that I have now inconsistencies between what I really have on disk and what urbackup actually reports.
I’ve seen similar issues but the solutions proposed often ìnvolved the nuclear option (reinstalling everything). I can do just that but I was wondering if there was another way. Something to force urbackup to look up again at the files on disk and get a closer value reported on the statistics. urbackup is working just fine as of now, it’s just a cosmetic issue, really.

6

I actually found the solution with a little help from chatgpt.
This involves :

  • stopping the urbackup container
  • backup the backup_server_files.db (just a safety measure since it is most likely… a bit messy)
  • run the defrag command in a temporary container (I needed to change the permissions on the file for that to work)
  • run the repair-database command (then revert the permissions back)
  • restart the urbackup container properly
  • urbackupsrv remove-unknown
  • run full file backups
    All good. Statistics are now consistent to the files on disk.
7

Great your statistics are fixed. However, the purpose of urbackup is to provide consistent backups of data rather than a set of file statistics. If you ever try to restore a backup you will likely get many urbackup errors because of missing files. You will certainly have missing files. Please don’t post on here asking how to fix them.

You have NO WAY of knowing what files have a backup history. NOONE should ever do this.

8

Some additional details : I forgot to mention that I end up removing all the backups one by one from the interface. So, after the maintenance mentioned earlier, I have no errors when restoring a file or downloading as zip.
Either way, you’re right, this is not how we’re supposed to use urbackup.