It would be nice if Duplicacy could support Scaleway C14 (Gacier)
While not specific to C14, there is quite a bit of discussion in this thread about some of the issues presented by cold storage.
Thanks for the link!
It seems like Glacier is not available due to Duplicacy needing some hot storage (metadata and the latest chunks)?
Why not put the metadata and the latest chunks on the hot storage, and put the old chunks to glacier?
Is what you’re describing the same thing as what’s described in this post and addressed in this one?
Or are you thinking of something different?
I was actually wondering if that could be implemented on software level. Something similar to ‘Prune’ process, except for this time, it sends it to archive and not delete. As S3 API (both S3 Glacier and C14) provides sending to glacier and vice versa/
If I understand correctly, in your suggested final state the config, snapshot files, and metadata chunks would all reside in hot storage. And all file chunks would reside in cold storage.
Seems okay, except for I think cold storage would still present issues if you ever want to prune or check your storage. In those cases I think you’d still have to unfreeze the file chunks for them to be accessible to the prune and check operations.
For now, I’ve set the ‘chunks’ folder to go to glacier after 1 day. I’ll see how this goes.
However, I think it would be awesome if Duplicacy had native support for these types of archival storage, so i can set the retention policy on Duplicacy itself and not on Scaleway. For example, files older than 2 days goes to Glacier, and when I click ‘retrieve’, Duplicacy automatically requests the needed chunks to be restored to normal (hot) storage. Iirc ArqBackup has something similar implemented with AWS Glacier