Backblaze bucket size is bigger that I expect

Getting Help
1

Hi there,

Is it a way to solve out why backblaze bucket size is bigger than restic stats.

It’s pretty new repo, actually I uploaded 4 directories and then (after few days) remove one of them with forget ID and prune

And second question. Should be locks* dir (with star) in repo? Does it mean the repo is locked somehow for any reason?

repository opened (version 2, compression level auto)
[0:00] 100.00%  2 / 2 index files loaded
scanning...
Stats in raw-data mode:
     Snapshots processed:  3
        Total Blob Count:  75534
 Total Uncompressed Size:  89.030 GiB
              Total Size:  88.243 GiB
    Compression Progress:  100.00%
       Compression Ratio:  1.01x
Compression Space Saving:  0.88%

but backblaze claims Current Size: 94.8 GB

From the very begginning I use Keep only the last version of the file

2

@webcaptcha
the reason of the size difference is due to the different unit of reporting.

GiB versus GB.
(gibityte versus gigabyte)
If you convert one to the other it matches.

3 Likes
3

Oh boy. Really. Thanks for pointed me out.

Since I already create topic, do you know about locks* dir?

One more difference is when run restic stats it shows Total Size: 89.384 GiB
while stats --mode=raw-data
show the results above

4

@webcaptcha,

I did never see a locks* folder hence I did not respond. There should be one locks folder without the * at the end.

  • What operating system do you use?
  • Can you paste the folder listing of your repository?

But I can help you again with the sizes. You can read the restic documentation for stats:
https://restic.readthedocs.io/en/stable/manual_rest.html#getting-information-about-repository-data

The default restic stats which gives you 89.384GiB is the size of the restored files.
Then the --mode=raw-data counts the size of the blobs in the repository. That is the deduplicated data size, your deduplicated repo size is

Total Uncompressed Size:  89.030 GiB

Last, since restic can also compress that result is also mentioned. your compressed repo size (this should mean actual occupied space on the disk) is

Total Size:  88.243 GiB

In conclusion you have source data with almost no duplicate data blobs and very little compression.

p.s. I find stats --mode =raw-data useful, to inspect the size or growth of the repository size.

5
  • config
  • data
  • index
  • key
  • locks*
  • snapshots

Those list from “Browse file” menu on backblaze
Ubuntu

restic list locks
enter password for repository:
repository  opened (version 2, compression level auto)

The locks* dir consists of 9 files with hash names

6

At the moment there is nothing strange in your output: restic stats will print the total “useful” data stored in the repo. BB will print the total “billable” space occupied.

Can you show us the output of restic prune --dry-run? I think you just have about 5Gb of unused space which you can prune with the right flags: by default prune will accept 5% of unused data.

If you complete the prune (without the --dry-run) the line “remaining” in prune should be really similar to what your provider will bill you for.

7

For now I’m ok with size anyway prune doesn’t show anymore to delete

Would have made the following changes:

to repack:             0 blobs / 0 B
this removes:          0 blobs / 0 B
to delete:             0 blobs / 0 B
total prune:           0 blobs / 0 B
remaining:         75534 blobs / 88.243 GiB
unused size after prune: 0 B (0.00% of remaining size)

The opened question is about locks* directory

Screenshot From 2025-01-11 12-02-27
Screenshot From 2025-01-11 12-02-27700×701 45.8 KB

8

First of all a list of hashes doesn’t contain anything sensible: there is nothing to hide and makes difficult to really see what is happening.

Anyway a simple google search for “blackblaze stars in directory listing” gives you the answer: all this files/dirs are deleted.

As expected the “locks*” dir wasn’t created by restic, and there are no locks left behind.

9

in this case backblaze should delete it in day or two I hope

10

It is not (or at least shouldn’t be) a question of hope:) but your B2 bucket Storage Lifecycle Rules settings. Simply it is entirely up to you how you configure it.

Restic has nothing to do with it.

1 Like
11

Regardless of I have option to keep only the last version, last time it tooks two days to finally shred the bucket size by backblaze