You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you checked borgbackup docs, FAQ, and open GitHub issues?
Yes
Is this a BUG / ISSUE report or a QUESTION?
ISSUE
System information. For client/server mode post info for both machines.
What kind of information?
Your borg version (borg -V).
Borg 1.4.0, and I've searched the master branch for this functionality.
Operating system (distribution) and version.
Debian 12 (Bookworm)
Hardware / network configuration, and filesystems used.
It varies, btrfs for source and ext4 for target (borg repository).
How much data is handled by borg?
Between eight and nine years of backups, which is the longest I've ever stuck with the same backup system. I just rant a "compact" operation and the current stats are:
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
All archives: 6.00 TB 4.86 TB 1.63 TB
Full borg commandline that lead to the problem (leave away excludes and passwords)
NA
Describe the problem you're observing.
Well, I'm surprised borg doesn't have this feature! As for the practical use, I find it easier to read narrow lines, which is allegedly the case for most people, and {unixtime} is the shortest recognisable way that I know of to insure unique archive names. It also actually means something when it's reversed, unlike pushing something unique through a hash function and then truncating the hash...which would also probably solve the unique archive name problem, although I'd worry about collisions.
Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.
Yes
Solution
int(time.time())
I hope you agree this sounds useful and fun to implement.
The text was updated successfully, but these errors were encountered:
It's just that it is more convenient with 2.0 to work a bit differently and use the "archive series" way of doing things.
Archives then all have the same name (e.g. "docs" or "home" or "system").
The timestamp, hostname, username are stored in separate metadata and displayed in "borg repo-list". This is much cleaner and has quite some nice effects, because then borg KNOWS what archives belong together:
can use memory more efficiently, e.g. files cache being smaller
no need for prefix/wildcard matching with prune, just can be a precise full match on the name
easy selection of the full series in general, just by name
single archive can be selected via its ID (hash). a unique prefix of the hash is sufficient (e.g. d34db33f is sufficient, no need to give all 256bits)
files cache can be rebuild from previous archive if lost / if not present, because borg knows what the previous archive is.
Have you checked borgbackup docs, FAQ, and open GitHub issues?
Yes
Is this a BUG / ISSUE report or a QUESTION?
ISSUE
System information. For client/server mode post info for both machines.
What kind of information?
Your borg version (borg -V).
Borg 1.4.0, and I've searched the master branch for this functionality.
Operating system (distribution) and version.
Debian 12 (Bookworm)
Hardware / network configuration, and filesystems used.
It varies, btrfs for source and ext4 for target (borg repository).
How much data is handled by borg?
Between eight and nine years of backups, which is the longest I've ever stuck with the same backup system. I just rant a "compact" operation and the current stats are:
Full borg commandline that lead to the problem (leave away excludes and passwords)
NA
Describe the problem you're observing.
Well, I'm surprised borg doesn't have this feature! As for the practical use, I find it easier to read narrow lines, which is allegedly the case for most people, and
{unixtime}
is the shortest recognisable way that I know of to insure unique archive names. It also actually means something when it's reversed, unlike pushing something unique through a hash function and then truncating the hash...which would also probably solve the unique archive name problem, although I'd worry about collisions.Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.
Yes
Solution
I hope you agree this sounds useful and fun to implement.
The text was updated successfully, but these errors were encountered: