Confusion between real size on disk and borg output sizes

[laur89]

After borg create, following message is shown in stdout:

------------------------------------------------------------------------------
Repository: ssh://[email protected]/./backups/repo
Archive name: vms-2023-02-13-055000
Archive fingerprint: bf2d3fd60a1024cf40ac3c721ae4b5463c5865395cf778476d3d713f8f4db4c7
Time (start): Mon, 2023-02-13 05:50:05
Time (end):   Mon, 2023-02-13 05:56:24
Duration: 6 minutes 19.07 seconds
Number of files: 1
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:               64.42 GB             42.27 GB                878 B
All archives:              515.40 GB            340.32 GB             70.79 GB

                       Unique chunks         Total chunks
Chunk index:                   37211               189533
------------------------------------------------------------------------------

What should be the actual size of /backups/repo on the remote? Because du -sm claims it's 556489.
Is this expected?

Client version is 1.2.0, server version 1.2.3

Edit: I've been living under the rock apparently. compact command was introduced by 9115ad5 (#3970)

[ThomasWaldmann]

Should be about 71GB.

Did you forget to invoke borg compact?

[laur89]

Well this is embarrassing... I didn't even have an idea of this, and my borg script has been in use since 2017.
Is following a reasonable order?

1. create
2. prune
3. compact (after prune, in order to make use of the freed space)

How come prune alone doesn't free the space up?

[infectormp]

https://borgbackup.readthedocs.io/en/stable/usage/prune.html

Repository disk space is not freed until you run borg compact.

Also read https://borgbackup.readthedocs.io/en/stable/usage/notes.html#separate-compaction

[ThomasWaldmann]

It's a good idea to read the changelog, if:

• the major release number changes, like 1.x.x -> 2.x.x - then you have to expect major and breaking changes
• the minor release number changes, like 1.1.x -> 1.2.x - then you have to expect bigger changes

The patch number changing, like 1.1.17 -> 1.1.18 usually indicates only small changes, like bugfixes or small improvements, but usually it's rather compatible.

[laur89]

You're absolutely right. I've just gotten used to treating minor ver bump as patch bump. Was bound to bite me in the ass at one point.