`ls`-like file view or `borg list --depth` to limit subdirectory recursion
Have you checked borgbackup docs, FAQ, and open GitHub issues?
I have checked the issue tracker for "borg list depth" and "borg list single folder" but to no avail. The documentation on "borg list" does not mention anything except --exclude. The FAQs do not mention this problem.
Is this a BUG / ISSUE report or a QUESTION?
ISSUE
... well a wishlish item kinda....
Your borg version (borg -V).
borg 1.4.0
Operating system (distribution) and version.
Rocky Linux 9
Hardware / network configuration, and filesystems used.
Four NUMA nodes, Intel(R) Xeon(R) CPU E7-4890, NFS-attached network disks
How much data is handled by borg?
500GB
Full borg commandline that lead to the problem (leave away excludes and passwords)
not applicable
Describe the problem you're observing.
If i have a backup I sometimes want to get an overview by browsing it similar to what I would do with cd and ls -- go into a directory, then see what's inside. With borg list, I always get a list of each and every subfolder and their files. I have found no argument like the -max-depth of the find utility to see only the direct contents of a folder.
It might be possible to cook up something with --exclude, but that takes forever, it probably lists the whole backup and filters afterwards.
Am I using this tool wrong as I seem to be the only one with this relatively simple problem? If you think it is worthwhile to add a borg ls or borg list --depth 1, that would be awesome!
Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.
not applicable
Include any warning/errors/backtraces from the system logs
no errors
Why don't you use the borg mount command and then any of the find\list etc commands on the mounted archive?
Hi, thanks for taking a look on this. I am not the administrator of the machine and fuse is not available here. The lighter system requirements of using a plain text shell would make things much easier for me.
https://borgbackup.readthedocs.io/en/stable/usage/list.html
You can maybe use the PATH argument or the patterns to list a specific folder or paths matching the pattern.
@ThomasWaldmann : This is a chicken and egg problem. How do I know what PATH arguments to use?
I have a similar wish and this is my use case:
I just realized that I don't think it is backing up /home/pmorch/superimportant since
$ borgbackup list ~/backup::myhost-2024-12-31T14:53:34.937714 | grep superimportant
But now trying to determine what it did backup is cumbersome:
$ borgbackup list --short ~/backup::pmorch7-2024-12-31T14:53:34.937714 > /tmp/list
$ wc -l /tmp/list
212237 /tmp/list
$ grep '^home/pmorch/.config' /tmp/list | wc -l
54418
$ grep '^home/pmorch/work' /tmp/list | wc -l
84487
$ grep '^home/pmorch/priv' /tmp/list | wc -l
73320
That doesn't make it easy to see that in fact only .config, work and priv were backed up from /home/pmorch. It is incredibly easy to miss the single line of /home/pmorch/supersecret/42.txt.
Here, this would've come in really handy:
# See that home is the top-level
$ borgbackup list --short --depth 1 ~/backup::pmorch7-2024-12-31T14:53:34.937714
home
# See what got backed up from $HOME
$ borgbackup list --short --depth 1 ~/backup::pmorch7-2024-12-31T14:53:34.937714 home/pmorch
.config
work
priv
One problem I have with mount is that I very often forget to unmount afterwards, leading to backups failing because mount locks the repo and this makes it bad to use also in scripts that may fail before unmount.
Hmm, can you try if that works for you?:
borg list REPO::ARCHIVE 'sh:*/*/*' # pattern corresponding to depth wanted
Sure:
$ borg list backup::pmorch7-2025-01-01T03:00:01.694095 'sh:*/*/*' | wc -l
212381
$ borg list backup::pmorch7-2025-01-01T03:00:01.694095 'sh:*' | wc -l
212381
Both list everything.
Also, assume that it did work as it looks like, this would give me everything "3 levels down". But I only whant the children of home/pmorch and not foo/bar's children also.
That would be a hacky workaround that importantly would limit the amount of data produced.
What I want is something that mimics the way I would iteratively investigate a normal directory tree:
ls /
ls /home
ls /home/pmorch
But I think personally, if I don't have that, I think I'll continue to do something like:
Extract full list of files
$ borg list --short backup::pmorch7-2025-01-01T03:00:01.694095 > /tmp/list
Find home/pmorch children (doesn't work for / or /home):
$ ack '^home/pmorch/[^/]+$' /tmp/list
home/pmorch/.borgmatic
home/pmorch/.config
home/pmorch/priv
home/pmorch/work
More generic but clunky approach:
$ perl -pe 's|^([^/]+).*|$1|' < /tmp/list | uniq
home
$ perl -pe 's|^(home/[^/]+).*|$1|' < /tmp/list | uniq
home/pmorch
$ perl -pe 's|^(home/pmorch/[^/]+).*|$1|' < /tmp/list | uniq
home/pmorch/.borgmatic
home/pmorch/.config
home/pmorch/priv
home/pmorch/work
Which works, but is rather clunky.
I am looking for the same feature.
In a cronjob, I would like to run borg check --verify-data ... followed by borg list ... to have periodic insight into the health of the backups. I don't want to be flooded with every file in the backup, just glance at the root directory.
I fiddled with --pattern syntax but was unable to get anything to work.
As recommended above, I decided to use borg mount and ls as a workaround. This seems to work, but I am concerned there may be performance considerations when the repo is on a remote server.
It would be nice if these work arounds were not needed.
Guess creating a full list with borg and then filtering it through grep and having grep filter out anything with more than N slashes could work.
I'd like to vote for this feature too. Missing it.
I'd like to have this too. I theoretically do have the option to mount, but my server and client are at opposite ends of the world, and going through the archive is extremely slow. SSHing remotely is technically possible, but is also laggy and is impractical for encryption modes where there is no remote key.
Would an interactive mode be an idea? That makes it a lot snappier to work with.