Sauvegarder LitArbi Server sur Amazon S3, pas à pas

Avant de commencer

Il vous faut trois choses : un compte Amazon Web Services auquel vous vous connectez en tant qu’administrateur, un compte administrateur sur votre LitArbi Server et un endroit sûr pour le kit de sauvegarde — le gestionnaire de mots de passe du cabinet, ou une imprimante et un coffre. Comptez 20 minutes ; la première sauvegarde se fait ensuite toute seule.

Les libellés AWS ci-dessous sont ceux de la console en anglais ; la langue se règle dans les paramètres de la console (icône d’engrenage en haut). Vous créez cinq choses, dans cet ordre :

Tout ce que le serveur envoie est chiffré avant de quitter le serveur, avec une clé que seul votre cabinet détient. Amazon stocke des données qu’il ne peut pas lire ; LitArbi non plus.

Coût. Amazon facture quelques centimes par gigaoctet et par mois pour le stockage à Francfort, plus des montants infimes par requête. Un serveur de 20 Go de pièces coûte bien moins d’un euro par mois.

Étape 1 — Créer le bucket

1. Connectez-vous à l’AWS Management Console. Dans le menu des régions en haut à droite, choisissez Europe (Frankfurt) eu-central-1 — ou une autre région de l’UE ; notez laquelle.
2. Ouvrez S3 (tapez « S3 » dans la recherche) et cliquez sur Create bucket.
3. Bucket type : General purpose. Bucket name : un nom unique, par exemple litarbi-backup-votrecabinet — minuscules, chiffres et tirets ; le nom ne doit être pris nulle part dans AWS.
4. Gardez les réglages par défaut : ACLs disabled, Block all public access coché, chiffrement par défaut SSE-S3.
5. Ouvrez Advanced settings. Sous Object Lock, choisissez Enable et cochez la case qui confirme que les objets pourront être verrouillés définitivement. Le versionnage s’active avec.
6. Cliquez sur Create bucket.

Object Lock ne s’active qu’à la création du bucket — et ne se désactive jamais. AWS propose ensuite une « default retention » : ignorez-la. LitArbi verrouille lui-même chaque fichier, pour le nombre de jours saisi à l’étape 5.

Étape 2 — La règle de nettoyage

Object Lock exige le versionnage, et avec lui une suppression ne fait que masquer le fichier. Quand LitArbi retire un ancien point de restauration, la règle supprime définitivement la copie masquée 30 jours plus tard.

1. Ouvrez le nouveau bucket, onglet Management, puis Create lifecycle rule.
2. Lifecycle rule name : litarbi-cleanup. Choose a rule scope : Apply to all objects in the bucket, et cochez la confirmation.
3. Sous Lifecycle rule actions, cochez Permanently delete noncurrent versions of objects et Delete expired object delete markers or incomplete multipart uploads.
4. Days after objects become noncurrent : 30. Laissez « Number of newer versions to retain » vide.
5. Cochez Delete expired object delete markers et Delete incomplete multipart uploads, Number of days : 7.
6. Cliquez sur Create rule.

Ne cochez pas « Expire current versions of objects » — cela supprimerait les sauvegardes elles-mêmes.

Étape 3 — La stratégie : ce que le serveur peut faire

1. Ouvrez IAM (tapez « IAM » dans la recherche), puis Policies et Create policy.
2. Passez l’éditeur de Visual à JSON, sélectionnez tout et remplacez-le par la stratégie ci-dessous. Mettez le nom de votre bucket aux deux endroits où figure litarbi-backup-yourfirm.
3. Cliquez sur Next. Policy name : LitArbiServerBackup. Cliquez sur Create policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBackupBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::litarbi-backup-yourfirm"
    },
    {
      "Sid": "ReadWriteBackupFiles",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:PutObjectRetention", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::litarbi-backup-yourfirm/*"
    }
  ]
}

Avec cette stratégie, le serveur peut lister, lire, écrire et supprimer les fichiers actuels de ce seul bucket. Il ne peut pas effacer les anciennes versions — s3:DeleteObjectVersion manque à dessein. Quiconque prend le contrôle du serveur peut donc seulement masquer des fichiers, jamais les détruire ; les copies masquées restent récupérables pendant 30 jours.

Si l’éditeur double les accolades ou les guillemets pendant la frappe, collez la stratégie au lieu de la taper.

Étape 4 — L’utilisateur du serveur et sa clé d’accès

1. Dans IAM, ouvrez Users et cliquez sur Create user. User name : litarbi-server-backup. Laissez décochée l’option d’accès à la console. Next.
2. Permissions options : Attach policies directly. Cherchez LitArbiServerBackup, cochez-la, Next, puis Create user.
3. Ouvrez le nouvel utilisateur, onglet Security credentials, et sous Access keys cliquez sur Create access key.
4. Cas d’usage : Application running outside AWS. Next, éventuellement la description « LitArbi Server », puis Create access key.
5. AWS affiche l’Access key (elle commence par AKIA) et la Secret access key — le secret une seule fois. Laissez la page ouverte pour l’étape 5.

Secret perdu ? Supprimez la clé d’accès, créez-en une nouvelle et saisissez la nouvelle paire dans LitArbi. Rien d’autre ne change.

Étape 5 — La page Backups de LitArbi Server

Dans LitArbi Web, ouvrez Administration ▸ Backups. La page a trois parties numérotées ; ses libellés sont en anglais.

1 · Backup key

Cliquez sur Create the backup key. La page affiche le kit de sauvegarde une seule fois : une clé LABK-… et son empreinte. Imprimez-le ou rangez-le dans le gestionnaire de mots de passe du cabinet, à l’écart du serveur, et faites en sorte qu’une deuxième personne sache où il se trouve. Le serveur ne garde que la moitié publique : il peut écrire les sauvegardes, jamais les lire. Sans le kit, personne ne peut les ouvrir — ni vous, ni votre hébergeur, ni Amazon, ni LitArbi.

2 · Backup place

Choisissez S3-compatible storage et remplissez :

Confirmez avec votre propre mot de passe LitArbi et cliquez sur Test and save. Le serveur écrit, lit et supprime d’abord un fichier de test : une erreur apparaît donc tout de suite (voir « En cas de problème » plus bas). Les accès sont conservés chiffrés sur le serveur.

3 · Keep restore points for

14 jours, 8 semaines et 12 mois sont un bon départ : le point de restauration le plus récent de chaque jour, semaine et mois est conservé. Les obligations professionnelles de conservation peuvent exiger davantage de mois.

Cliquez enfin sur Back up now. La première sauvegarde envoie tout et peut durer un moment — elle continue en arrière-plan. Les suivantes n’envoient que ce qui est nouveau.

Étape 6 — Vérifier que tout fonctionne

• Sur la page Backups, Last backup affiche la date du jour et At the backup place votre bucket avec « Object Lock 30 days ».
• La vue d’ensemble n’indique plus qu’aucune sauvegarde n’est configurée.
• Saisissez la clé de votre kit sous Check the kit. Elle ouvre une fois le point de restauration le plus récent et n’est pas conservée — la preuve que le kit fonctionne avant que vous en ayez besoin.
• Check the backups compare le point de restauration le plus récent avec ce qui a été envoyé ; le serveur le refait seul chaque semaine.

La sauvegarde tourne en arrière-plan par courtes tranches pendant l’utilisation de LitArbi. Si votre hébergement propose des tâches cron, il est plus fiable de la lancer chaque nuit à heure fixe — le guide d’installation fourni avec le serveur donne la ligne.

En cas de problème

Si Test and save échoue, la page affiche la raison donnée par Amazon. Les plus courantes :

Autres fournisseurs S3

Tout stockage compatible S3 fonctionne de la même façon — par exemple Hetzner Object Storage, IONOS S3 Object Storage, Backblaze B2 ou Wasabi. Trois points comptent partout :

• Activer Object Lock (et avec lui le versionnage) à la création du bucket, si le fournisseur le propose.
• Créer une clé d’accès limitée à ce seul bucket, si le fournisseur le permet.
• Reprendre l’endpoint et la région dans la documentation du fournisseur et les saisir à l’étape 5.