TW
also wondering why a not-first backup takes that long. does the dedup not work or is it really lots of NEW data?
ok. iirc there is some `--upload-buffer` (or so) option, maybe you can try using that to speed it up. you use some fast compression (default is lz4, zstd,1 .. zstd,3...
another idea is not to use different repo for partitions of the data, but for different times. not pretty, but would work: use a different repo depending on weekday.
--upload-buffer is about buffering, not compression.
Maybe the following semantics makes sense: Differentiate between: - `borg check` ("is everything ok?") - `borg check --repair` ("i know something is broken and want it repaired") borg check: -...
@enkore borg currently does a lot using localtime, but has no real timezone support (likely would require pytz). So I am not totally sure that even now all timestamps shown...
I am not sure this can be done cleanly without having aware datetime objects everywhere, so it might need a bit more work than just using a different format string...
A first step could be to use the yyyy-mm-ddThh:mm:ss format without tz (so, no weekday and the T separator would be the difference to the human-readable iso-like format we use).
partially addressed by #2925 (no tz yet), nothing to do left for 1.1 milestone.
Yeah, would be good timing. But already a ton of other todo, do you want to work on it?