Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add {unixtime} to placeholders #8522

Open
sten0 opened this issue Nov 5, 2024 · 3 comments
Open

Please add {unixtime} to placeholders #8522

sten0 opened this issue Nov 5, 2024 · 3 comments

Comments

@sten0
Copy link

sten0 commented Nov 5, 2024

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.

@ThomasWaldmann
Copy link
Member

@sten0 Yeah, should be easy to implement.

Guess we would only have that in borg 1.x though, because borg2 does not require archive names to be unique anymore.

@dietmargoldbeck
Copy link

@sten0 Yeah, should be easy to implement.

Guess we would only have that in borg 1.x though, because borg2 does not require archive names to be unique anymore.

Please add it to 2.0 also. It improves readability for backup names even when not needed and borg 2.0 should be as compatible to borg 1.4 as possible.

@ThomasWaldmann ThomasWaldmann modified the milestones: 1.4.x, 2.0.0b14 Nov 6, 2024
@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented Nov 6, 2024

Yeah, I can add it to 2.0, no problem.

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.
  • less duplication in "borg repo-list" output

@ThomasWaldmann ThomasWaldmann modified the milestones: 2.0.0b14, 2.0.0b15 Nov 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants