Sauvegarde et restauration

Kuploy peut sauvegarder et restaurer l'instance entière — sa propre base de données et sa configuration, qui contiennent toutes les organisations de ce déploiement. C'est un outil de reprise après sinistre, à l'échelle de l'exploitant, distinct des sauvegardes de bases applicatives que configurent vos développeurs — et distinct de la sauvegarde continue avec restauration à l'instant près de la plateforme, qui protège minute après minute les données vivantes comme les boîtes aux lettres.

Tout ce qui suit se trouve sous Settings → Maintenance, et n'est accessible qu'aux administrateurs de l'instance.

Sur Kuploy Cloud

C'est un outil d'exploitant : sur Kuploy Cloud, il se trouve donc sous Platform Admin → Maintenance, et est réservé aux administrateurs de plateforme — les personnes qui font tourner le déploiement. Les propriétaires et administrateurs d'organisation ordinaires, les locataires, n'y accèdent pas : l'outil agit sur la base de données partagée de la plateforme, qui contient toutes les organisations, et jamais sur les données d'un seul locataire. Tout ce qui suit s'applique à l'identique ; seul l'emplacement diffère — Platform Admin → Maintenance, et non Settings → Maintenance.

C'est l'instance entière

Une sauvegarde d'instance capture tout : toutes les organisations, tous les utilisateurs, tous les projets et tous les réglages. En restaurer une ramène l'instance entière à cet instant, et non une seule organisation. Traitez-la en conséquence.

Prérequis

• Vous devez être connecté en tant qu'administrateur de l'instance — le premier utilisateur créé sur une instance neuve en est un.
• Au moins une destination S3 : un bucket dans lequel kuploy peut téléverser ses sauvegardes. Si vous n'en avez pas encore, suivez Configurer un bucket AWS S3, ci-dessous.

Configurer un bucket AWS S3

Vous n'avez à le faire qu'une fois. Ces étapes utilisent Amazon S3 ; n'importe quel prestataire compatible S3 (Cloudflare R2, Wasabi, MinIO, DigitalOcean Spaces…) fonctionne de la même manière — seul l'Endpoint diffère.

1. Créer le bucket

1. Dans le sélecteur Region, en haut à droite de la console AWS, choisissez la région où doit résider le bucket — par exemple US East (Ohio) us-east-2. Notez le code de la région : vous en aurez besoin plus bas. (Le formulaire de création de bucket affiche cette région sous General configuration ; ce n'est pas un champ à part.)
2. Ouvrez S3 → Buckets → Create bucket.
3. Bucket type — laissez General purpose.
4. Bucket namespace — laissez Global namespace, la valeur par défaut.
5. Bucket name — un nom unique au monde, par exemple mes-sauvegardes-kuploy.
6. Object Ownership — laissez ACLs disabled (recommended).
7. Block Public Access — gardez Block all public access coché : vos sauvegardes doivent rester privées.
8. Bucket Versioning — éventuellement, passez-le sur Enable, pour qu'un objet de sauvegarde écrasé ou supprimé reste récupérable.
9. Laissez le reste par défaut — chiffrement, étiquettes — et cliquez sur Create bucket.

2. Créer une politique IAM circonscrite

N'accordez à kuploy l'accès qu'à ce seul bucket. Dans IAM → Policies → Create policy, passez à l'éditeur JSON et collez ceci, en remplaçant mes-sauvegardes-kuploy par le nom de votre bucket :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "KuployBackupsBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::mes-sauvegardes-kuploy"
    },
    {
      "Sid": "KuployBackupsObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::mes-sauvegardes-kuploy/*"
    }
  ]
}

Nommez-la par exemple kuploy-backups, et créez-la.

3. Créer l'utilisateur IAM

1. Dans IAM → Users → Create user, nommez-le par exemple kuploy-backups, et laissez Provide user access to the AWS Management Console décoché.
2. À l'étape Set permissions, choisissez Attach policies directly, recherchez kuploy-backups, cochez-la, et terminez la création de l'utilisateur.

Créer l'utilisateur ne génère pas de clé d'accès : c'est une étape distincte, ci-dessous.

4. Créer une clé d'accès

1. Ouvrez l'utilisateur (IAM → Users → kuploy-backups) → onglet Security credentials → Create access key.
2. Pour Use case, choisissez Application running outside AWS → Next.
3. Passez l'étiquette de description facultative → Create access key.
4. Sur l'écran Retrieve access keys, copiez tout de suite l'Access key ID et la Secret access key — le secret n'est affiché qu'une fois (ou faites Download .csv).

5. Ajouter la destination dans kuploy

Allez dans Settings → S3 Destinations → Add Destination, et remplissez :

Champ	Valeur
Name	Un libellé de votre choix, par exemple Sauvegardes AWS
Provider	Amazon Web Services (AWS) S3
Access Key Id	L'Access key ID de l'étape 4
Secret Access Key	La Secret access key de l'étape 4
Bucket	Le nom de votre bucket, par exemple mes-sauvegardes-kuploy
Region	La région de votre bucket, par exemple us-east-2
Endpoint	https://s3.<région>.amazonaws.com, par exemple https://s3.us-east-2.amazonaws.com

Où trouver ces informations

Ouvrez le bucket dans S3 → Buckets → mes-sauvegardes-kuploy → Properties → Bucket overview : vous y lisez l'AWS Region (us-east-2, par exemple) et l'ARN du bucket (arn:aws:s3:::mes-sauvegardes-kuploy). Le champ Bucket ci-dessus n'est que le nom, et l'Endpoint vaut https://s3. + cette région + .amazonaws.com.

Cliquez sur Test connection pour vérifier les identifiants, puis sur Create.

Sauvegarder l'instance

1. Allez dans Settings → Maintenance → Backups → Create Backup.
2. Choisissez votre Destination, une Schedule (en syntaxe cron) et, éventuellement, un Prefix — un dossier à l'intérieur du bucket.
3. Keep the latest — éventuellement, plafonnez le nombre de sauvegardes conservées ; les plus anciennes sont élaguées automatiquement. Laissez le champ vide pour toutes les conserver : aucun élagage, c'est la valeur par défaut.
4. Enregistrez. L'action Run (▶) sur une sauvegarde en déclenche une immédiatement ; sinon, laissez la planification s'en charger. L'icône de liste de contrôle d'une sauvegarde énumère ses exécutions récentes, avec leur état et leurs journaux.

Chaque sauvegarde est une archive unique, dans votre bucket, qui contient la base de données de l'instance et ses fichiers de configuration.

Restaurer

La restauration s'atteint depuis Settings → Maintenance → Backups → Restore Backup. Choisissez la destination et le fichier de sauvegarde, puis choisissez où restaurer.

Restaurer vers une nouvelle base (recommandé)

Restaure la base de la sauvegarde dans une base séparée et vide que vous fournissez : la base et le système de fichiers de l'instance en service ne sont jamais touchés. Servez-vous-en pour valider une sauvegarde, monter un clone, ou migrer vers une infrastructure neuve. C'est sans danger et sans garde-fou, puisque rien ne change sur l'instance en service.

1. Préparez une base cible vide sur votre serveur Postgres. Elle doit déjà exister — la restauration la remplit — et devrait être vide :

   CREATE DATABASE kuploy_restore;

2. Dans Restore Backup, choisissez votre Destination et le fichier de sauvegarde (instance-backup-<horodatage>.zip).

3. Sous Restore to, choisissez New / external database.

4. Dans Target database URL, saisissez la chaîne de connexion de cette base vide — par exemple postgresql://utilisateur:motdepasse@hote:5432/kuploy_restore.

5. Cliquez sur Restore et suivez le journal jusqu'à « Restore completed successfully! » — un message de réussite s'affiche également.

6. Vérifiez la copie, en vous connectant à la cible et en contrôlant que vos données y sont bien arrivées :

   SELECT name FROM organization;
   SELECT name FROM project;

7. Pour faire réellement tourner la copie restaurée, faites pointer une instance kuploy neuve sur cette base, par son DATABASE_URL. À son premier démarrage, elle réappliquera les migrations plus récentes (voir la note ci-dessous).

« Ignored, non-fatal errors »

Le journal de restauration peut se terminer par pg_restore reported ignored, non-fatal errors. C'est normal lorsque la sauvegarde a été prise avec un Postgres plus récent que la cible — un SET transaction_timeout que le serveur plus ancien ne connaît pas, par exemple : la restauration aboutit tout de même. Utilisez des versions majeures de Postgres identiques si vous voulez un journal propre.

La restauration sur place (destructive)

Écrase la base de données et la configuration de l'instance en service, ramenant toutes les organisations à la sauvegarde. À n'utiliser que pour une véritable reprise après sinistre.

Parce qu'elle est irréversible, kuploy vous demande de saisir le nom de l'instance pour confirmer, et prend automatiquement une sauvegarde préalable fraîche, afin que vous puissiez récupérer l'état courant au besoin.

Après la restauration d'une sauvegarde ancienne

Restaurer une sauvegarde de base entière ramène aussi le schéma de l'instance à la version de cette sauvegarde. Au démarrage suivant, kuploy réapplique ses migrations pour rattraper le schéma. Laissez-les converger avant de faire confiance à l'instance, et envisagez un Clean Redis ensuite, pour vider le cache et les sessions qui renvoient à l'état d'avant la restauration.

L'historique des restaurations

Chaque restauration est consignée et listée sous Settings → Maintenance → Restore history, la plus récente d'abord — avec son état (running, done, error), son type — sur place ou vers une nouvelle base —, le fichier de sauvegarde et sa destination, la date d'exécution, et toute erreur survenue. Servez-vous-en comme piste d'audit : ce qui a été restauré, et avec quel succès.

Les autres actions de maintenance

• Reload Server — relance le processus du serveur web. Le panneau est brièvement indisponible, le temps qu'il redémarre.
• Clean Redis — vide le Redis de l'instance, effaçant l'état en cache et les sessions de toutes les organisations qui s'y trouvent. Exige une confirmation saisie à la main. Vos utilisateurs restent inscrits, mais devront se reconnecter.