anything else that we should change in an incompatible way?

[ThomasWaldmann]

if you can think of rather small but incompatible changes in borg, 1.0 (== now) is a good time to do them.

so please either discuss below or link to a new ticket from below, so we can decide whether it shall go in now or later at 2.0.

[pszxzsd]

Could it be beneficial to raise the repo segment size? Maybe to a multiple of the new default chunk size?

[ThomasWaldmann]

@pszxzsd yes, that's something to consider. #599

[ghost]

I'd like to suggest changing the function names of "create" and "extract" to more familiar "backup" and "restore" terms respectively.

[ThomasWaldmann]

Opinions about Orbixx' suggestion? +1 / -1 please.

[jdchristensen]

I have to admit that when I haven't manually run borg for a while, I sometimes type "borg create" when I mean "borg init". I think "borg backup" would be more clear. I don't have a strong preference between "extract" and "restore", but "restore" is probably more familiar to new users. On the other hand, "create" and "extract" match the terminology of tar... Overall, maybe not worth making a change?

[ThomasWaldmann]

I've thought about it and I tend not to change it, because it reads now as:

borg create ARCHIVE
borg extract ARCHIVE

These are complete sentences and totally make sense, while these don't:

borg backup ARCHIVE
borg restore ARCHIVE

So, -1 from me.

[ghost]

Create is such a basic, vague word though that could apply to many things. Like Dan mentioned, it's easy to mix up init and create.

Of course with the context it makes sense, but by changing it to "backup" you already have the context without having to read the rest of the arguments to figure out what is going to be created.

I don't think it's particularly important and Borg would hardly suffer if this did not change, but I think in terms of usability, my suggestion would be better.

Also, depending on how much you want to distance yourself from Attic, it might be beneficial to change arguments to force people moving from Attic to Borg to re-examine their Attic arguments to see if they should be changing them for Borg.

[losvald]

What exactly happens if you mix different compressions in the same repo/archive. For instance, I tried adding 10G of data using lz4, then changed 100MB and backed up using lzma. It looks like the old deduplicated data remembers the compression algo (only newly deduplicated data is compressed with lzma)?

Moreover, even if a run prune or delete the snapshot which used lz4 compression, the lzma snapshot is still "depending on". Shouldn't we support a --[no-]recompress option and even consider changing the default behavior?

This has serious implications: A user is "locked down" to the space usage / compression ratio used by the very first backup command that created each piece of (newly) deduplicated data.
(The only way around I see would be to mount all efficiently compressed snapshots, then create a new archive and compress only those snapshots using the desired compression. Such a migration to save space is not only clumsy but will also lose timestamps information!)

[ThomasWaldmann]

@losvald Sure, it does not recompress all data chunks that you ever stored into the repo. That would be expensive (time, transfer at least) and also slightly dangerous (a lot of stuff needs touching).

The storage is key/value kind and deduplication is based on the key, which is the hash/hmac of the before compression or encryption happens. So it is not possible to have the same chunk one time compressed with x and one time compressed with y, because they have bot the same key. It would be possible to recompress though, but see above.

That's not necessarily an incompatible change, it could still default to not recompress (like now) and give the option to --recompress.

See there for more: #630

[ThomasWaldmann]

OK, closing poll now, thanks for your feedback.