Questions about zstd-compression

Support
,
#1

Hi, I just wanted to confirm something regarding the new-ish zstd support. Basically I want to know about how seamless the implementation is…

  1. Starting to use zstd-compression on a non-zstd repository (it now contains both compressed and non-compressed data), will a restore cause problems?
  2. Can I restore a mixed (as above, compressed and non-compressed data) repository with and without the zstd-option?
  3. What happens if I initialize a zstd-enabled repository without the zstd-option?
  4. Is the zstd-option on backup-commands necessary if the repository was initialized with the zstd-option?
#2
  1. No
  2. Yes.
  3. You can’t initialize repository that is already initialized. Everything in the init command is ignored and existing storage is added to the list. It should have been called “adopt”
  4. No
#3

Thanks.

In regards to my third point, I was thinking specifically about using the init-command to set up a complete restore. That is, from nothing.

I assume the zstd-option is for outbound traffic only, which means duplicacy will decompress as necessary when downloading regardless of whether or not the zstd option was used when executing init?

#4

The init on existing storage, as it is in case of restore from scratch you describe, does not alter storage configuration, it just adds reference to the storage to the list of storages in the current new empty repository. That’s why it should have been called “adopt” instead.

The default compression parameters are stored on the storage in the configuration file. That’s what will backup command use unless you overwrite it with command line parameters. That file is called ‘config’, is written once and never modified for the life of storage location.

Storage can contains chunks compressed with different compression algorithms and/or parameters. The compression scheme of a specific chunk is stored within that chunk. Restore command will read that and use to recover the data

1 Like