-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(backups/mirror): filter backup to be transfered #7748
Conversation
65b0815
to
fee3a23
Compare
4083cb6
to
65d46f0
Compare
after working on it this afternoon, I think it's not a good idea to use a generic filter on incremental backups, since transferring a partial chain will silentlty break the replicated backups, or we must add a lot of magic to rebuild a reasonnable chain I would advise that the generic filter should be implemented when we rework the mirro backup to fuse incremental/full mirror job in one ( this is also a type of filter ) |
1ef5c10
to
4950121
Compare
dc64c66
to
4950121
Compare
8ab1a45
to
555436a
Compare
555436a
to
8757d52
Compare
the algorithm sorting the backup to transfer do not take into account multiple job writing to the same remote It can lead to additional VM being transferred
If the user defined a filter and the filter only match part of the full backups, then we'll only transfer the matched backups If the user is using incremental backup, then we'll trnsfer the full chain if at least only one match
8757d52
to
3aeeb57
Compare
Description
value-matcher
. For example filtering by vm uuid would be :{ vm: { uuid: { __or: ["foo", "bar"] } } }
where foo and bar are vm uuidsexcluded VM are visible in thebackup execution logs, with a specific information message
Checklist
Fixes #007
,See xoa-support#42
,See https://...
)Introduced by
CHANGELOG.unreleased.md