Hello Ede,
Thanks for your quick reply.
I should have mentioned that I use --no-compression on the duplicity
command-line.
So I do not know at which step this argument intervene.
Thank you,
Nate
Le sam. 14 janv. 2023 à 15:41, edgar.soldin--- via Duplicity-talk
<duplicity-talk@nongnu.org <mailto:duplicity-talk@nongnu.org>> a écrit :
hey Nate,
On 14.01.2023 15:26, Nathan MALO via Duplicity-talk wrote:
> Hello,
>
> My backup strategy consists of making a master every 30days and then
making incremental backups between masters.
>
> I also have a multi backend : local disk and ftp with different
retention policy.
>
> Currently the ftp backend has one primary chain and two secondary ones.
The local disk has one primary chain. The next master will be made in about three
weeks.
>
> I have always done my backups uncompressed encrypted.
>
> Will there be any issue if I enable compression in the middle of the
primary chain, or should I wait for the new master to be created ?
assuming you are talking about enabling compression in gpg via
`--gpg-options` i would assume that this wouldn't be an issue. afaik gpg will
silently detect the used compression or not and decrypt.
regardless, i would advise you to do a local test. backup a small test data set gpg
encrypted to a file:// target, do a full, some incrementals, add e.g.
`--gpg-options="--compress-algo=bzip2 --bzip2-compress-level=9"`, do some more
incrementals.
not try to restore/verify each of these, just to make sure the switch
didn't break anything.
good luck.. ede/duply.net <http://duply.net>
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk@nongnu.org <mailto:Duplicity-talk@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
<https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk