Analyze/show disk space used by snapshots

[Germar]

It would be very useful to be able to browse backups by actual size (with dereferenced hardlinks) and by files that were explicitly modified. I make full disk backup using BiT and would like to see what takes a lot of room (to possibly exclude some directories that only contain dynamic data). It would also be really helpful to know if a file is part of a specific snapshot or a hardlink from an older snapshot.

---

Imported from Launchpad using lp2gh.

• date created: 2012-04-13T13:49:26Z
• owner: xsmurfster+launchpad
• the launchpad url was https://bugs.launchpad.net/bugs/980814

[Germar]

(by danleweb)
From command line you can use "du" (disk usage) to get the size "on disk" used by a file or directory.
This tool handle correctly hardlinks.

Regards,
Dan

[Germar]

(by tmetro+ubuntu)
"Disk Usage Analyzer" is one of several GUI tools that will show you graphs of how storage space is allocated among directories and files on a selected path. You can browse to your BiT target directory and run it.

I just tried this, and it apparently does intelligently report space used by hard linked files only once. If you look at the attached screen shot, you'll see my initial snapshot from November is taking up 50% (69 GB) of the relative space (138 GB total), then one from February is taking up 36% (49 GB), and then most of the subsequent snapshots are taking up 2% or less.

Although "Disk Usage Analyzer" thinks the February backup has a significant quantity of unique files, I don't expect this is reality, and I think it is more a side effect of the order in which "Disk Usage Analyzer" happened to process the files. When it runs across a hard linked file, I don't know whether it assigns the space it takes up to the first or last directory it is found in. And I don't know if it processes the directories in sorted order.

In order for the report to make most sense for BiT you'd want it to process the directories in a consistent order - lets say ascending alpha-numeric - and then assign space for linked files to the first directory in which they are encountered.

It would seem that with a few tweaks to the "Disk Usage Analyzer" source this could easily be accomplished, and then BiT could include a button that launches "Disk Usage Analyzer" pointed at the directory containing the snapshots for the current profile. It would be a fairly small amount of integration effort for a nice functionality gain.

[buhtz]

@emtiu
I was referenced to this Issue by #1162

After studying it I vote for close because the described functionality is out of scope of BiT. Especially on Linux there are some very nice tools to analyze used storage space also with taking hardlink into account.

[emtiu]

I think this is a useful feature to have, as it would greatly help with snapshot and disk space management.

Note that you can already do this manually outside of backintime (at least on Linux, as far as I'm aware), by simply using du -s – which only counts hardlinked files' space usage once in a single call.

For example, here's my snapshots directory:

$ du -sh *
236G    20220814-230001-308
1,1G    20220816-230001-445
573M    20220817-230001-441
812M    20220818-230001-744
708M    20220819-180001-498
[...]

(Interestingly, it's almost the same issue as with filesystem snapshots in ZFS. They are incremental in nature (because ZFS is a copy-on-write filesystem), and space usage per snapshot is a big topic for many users of the filesystem.)

Even though du -s can solve this problem with some fiddling, I'd expect backintime to have some mechanism of informing users about the (incremental) space usage of its snapshots, so I suggest we keep this open as a feature request.

[emtiu]

Oh, and let's not forget #1162 as a good idea to implement this :)

[jondo]

My use case would be: How much disk space would be freed by deleting snapshot X? (I'd call this the inner size.) For this, the output of du -sh * does not work: When file a is contained in snapshots 1 and 2, and file b in 2 and 3, deleting neither of the snapshots would free any disk space.