Duplicity uses "all files changed since the last backup of any type”, incremental are cumulative and a corrupted incremental backup will cause subsequent incrementals to have issues.
The Manifest files are synchronized between the remote and client. These may need frequent access.
I use Wasabi which is normal AWS compatible storage for almost glacier pricing. Avoids having to try to anticipate all possible usage.
-Scott
On Aug 16, 2018, at 4:01 PM, David Potter via Duplicity-talk <
[hidden email]> wrote:
I am trying to plan an approach to using duplicity with AWS. Here are some important questions that you might help advise me on. Please direct me to documentation for these if it exists:
- In Duplicity, does "incremental" have the meaning of "all files changed since the last backup of any type" (usually called incremental), or "all files changes since the last full backup" (sometimes called "progressive")?
- I intend to store my backups on S3. Are there any documents that describe recommended methods for minimizing my storage and transfer costs when using Duplicity? For example:
- I'd like to use bucket transition rules to move files to Glacier when I expect that they won't be needed for a while. Which files (if any) does Duplicity commonly access during subsequent backups?
- Are there metadata files that are commonly accessed and should remain in S3, while actual data files can be shoved over to Glacier? If so, how do I recognize and differentiate these files?
- Are there ways to organize my backups into S3 buckets in order to reduce the number of files that need to be online when I perform a small restore from an incremental backup?
Thanks,
_______________________________________________
Duplicity-talk mailing list
[hidden email]https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Locked
