Sauvegarde et restauration

Votre application est en production. Assurez-vous de la sauvegarder. rdc peut pousser votre dépôt entier (application, base de données, fichiers, configurations) vers un stockage externe et le récupérer à tout moment. Résistez aux ransomwares, aux pannes matérielles, à tout.

Regarder le tutoriel

Trois étapes

Configurer, pousser, restaurer

Configurer un fournisseur de stockage.
Pousser une sauvegarde.
Restaurer quand vous en avez besoin.

Étape 1 : Configurer le stockage

Vous avez besoin d’un fichier de configuration rclone. Si vous utilisez déjà rclone, importez-le directement :

rdc config storage import --file rclone.conf

Importez une configuration rclone existante. rclone prend en charge S3, Backblaze, Google Drive, Dropbox, et bien d'autres. Si vous utilisez déjà rclone, la même configuration s'importe directement.

Cela prend en charge S3, B2, Google Drive, Dropbox et bien d’autres. Vérifiez ce qui est configuré :

rdc config storage list

Listez les stockages que le CLI connaît désormais. Chacun est une destination pour les sauvegardes.

Étape 2 : Pousser une sauvegarde

rdc repo push --name my-app -m <machine-name> --to my-storage

Envoyez une sauvegarde complète. L'intégralité du repository est téléversée, incluant l'application, la base de données, les fichiers et la configuration. Comme le repository est chiffré au repos, la sauvegarde est également chiffrée, sans gestion de clés supplémentaire.

Votre dépôt entier (application, base de données, fichiers, tout) est maintenant sauvegardé. Comme le dépôt lui-même est chiffré, la sauvegarde l’est aussi. Aucune gestion de clé supplémentaire.

Listez vos sauvegardes à tout moment :

rdc repo backup list --from my-storage -m <machine-name>

Listez les sauvegardes disponibles sur ce stockage. La restauration sur un tout nouveau serveur se fait en une seule commande : la commande repo pull.

Pourquoi aucun temps d’arrêt ?

L’application continue de tourner pendant que la sauvegarde se téléverse. Comment est-ce cohérent ?

Même logique qu’un fork. rdc forke d’abord, puis téléverse le fork. Le fork capture l’instant ; votre application en direct continue. Aucun temps d’arrêt, aucune incohérence.

Étape 3 : Restaurer, pour de vrai

Une sauvegarde qu’on ne restaure jamais, c’est un espoir, pas une sauvegarde. Mettez d’abord le dépôt hors ligne :

rdc repo down --name my-app --machine <machine-name> --unmount

Mettez d'abord le repository hors ligne : arrêtez les services et démontez le volume chiffré avec la commande repo down.

Récupérez directement la sauvegarde depuis le stockage :

rdc repo pull --name my-app --machine <machine-name> --from my-storage --force --yes

Récupérez la sauvegarde depuis le stockage avec la commande repo pull. L'image est récupérée et son intégrité est vérifiée.

Et remontez-le, entièrement restauré :

rdc repo mount --name my-app --machine <machine-name>

Montez à nouveau le repository, il est entièrement restauré. La même opération pull fonctionne sur une toute nouvelle machine.

Le même pull fonctionne sur un tout nouveau serveur : configurez-le, ajoutez-le à rdc, et lancez le pull depuis là.

rdc repo pull --name my-app -m new-server --from my-storage
rdc repo up --name my-app -m new-server

Référence CLI : rdc repo pull · rdc repo up

Mêmes données, mêmes conteneurs, machine différente.

Sauvegardes plus rapides : de machine à machine

Vous pouvez également pousser directement entre machines, sans stockage cloud intermédiaire :

rdc repo push --name my-app -m my-server --to-machine backup-server

Référence CLI : rdc repo push

Conseil pro. Les pushs de machine à machine n’envoient que les blocs modifiés après le premier. Le tutoriel Transfert delta le montre en direct.

Suivant : Réseau et domaines.