Backup & Restore

[leleueri]

Step1:
On backup task:

• wait the response of each Sidecar
• Each sidecar :

• snaphost the node synchronously
• push files ref to upload into a in memory queue
• upload files asynchronously from the queue content

Step2:

• Provide an operator endpoint to know if there are some backup in progress
• schedule the file upload if there are new snapshot triggered by another tool (like reaper)

Step3 :

• manage retention period

[vroyer]

Yes ! Et pour la restoration, 2 possibilités : 1-restart du pod avec download des stables dans un init container. La restore doit se faire sur un DC ayant les mêmes token ranges que celui du backup 2-restore d’un snapshot sur un DC ayant des token range différents de ceux du backup => pas de restart du pod, mais a. Initialisation par l’opérateur d’un table CQL “stables_restore_snapshotX” listant les SSTable à restaurer dispo sur le blobstore. b. lancement sur les sidecar d’un thread qui pioche une ligne stables_restore_snapshotX, la verrouille avec un update PAXOS, et la restore via SSTableRestore, jusqu’a ce que tous les tables soient restaurées. C’est la transaction PAXOS qui garantie que tous les table sont restaurées exactement une fois ! Cldt, Vincent.

…

On 5 Dec 2019, at 16:21, Eric ***@***.***> wrote: Step1: On backup task: wait the response of each Sidecar Each sidecar : snaphost the node synchronously push files ref to upload into a in memory queue upload files asynchronously from the queue content Step2: Provide an operator endpoint to know if there are some backup in progress schedule the file upload if there are new snapshot triggered by another tool (like reaper) Step3 : manage retention period — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#34>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOMPGM5YJXQPUTGSRC3UZLQXEL6DANCNFSM4JV3GT6A>.