Nimbus Backup 0.4.1 : chiffrement compatible proxmox-backup-client et binaires signés

Des binaires signés

NimbusBackup.exe, le service et l'installateur NimbusBackup.msi sont signés (Authenticode), via Azure Artifact Signing, avec un certificat au nom de RDEM SYSTEMS (Pontoise, FR). Les exécutables sont signés avant d'être empaquetés dans le MSI, puis le MSI lui-même. Les outils en ligne de commande, livrés à part dans l'archive nimbus-backup-cli, ne sont pas signés.

La CI vérifie chaque fichier livré, y compris les exécutables contenus dans le MSI : statut Valid, signataire RDEM SYSTEMS, horodatage. Sinon, le build échoue.

RDEM SYSTEMS s'affiche comme éditeur vérifié ; l'avertissement SmartScreen peut subsister tant que la réputation n'est pas établie. Le certificat est neuf, et sa réputation part de zéro. Si SmartScreen s'affiche encore, vérifiez que l'éditeur est bien RDEM SYSTEMS, puis cliquez sur Informations complémentaires, puis Exécuter quand même.

Get-AuthenticodeSignature .\NimbusBackup.msi | Format-List Status, SignerCertificate

Les empreintes SHA-256, l'attestation de provenance et les rapports VirusTotal restent publiés à chaque version ; nous les détaillons sur la page faux positif antivirus.

Le chiffrement de tizbac, compatible avec proxmox-backup-client

Ce chiffrement a été développé en amont par Tiziano Bacocco, dans tizbac/proxmoxbackupclient_go. La 0.4.1 l'intègre dans notre build, en remplacement de notre propre implémentation, qui n'avait pas été publiée. Merci Tiziano.

Les blocs sont chiffrés en AES-256-GCM sur la machine sauvegardée, au même format que le client officiel proxmox-backup-client : le serveur PBS ne reçoit que des données chiffrées et ne voit jamais la clé. Dans l'interface : Configuration PBS → Modifier → Clé de chiffrement, puis créez un fichier de clé ou choisissez-en un existant ; son empreinte s'affiche.

La compatibilité est vérifiée par la CI à chaque build, sur un vrai PBS :

• un dossier chiffré par Nimbus Backup, avec une clé créée par le client officiel, est restauré par le client officiel avec la même clé, et refusé sans elle ;
• une sauvegarde de disque chiffrée par le client officiel est relue par Nimbus Backup ;
• à chaque build, PBS lui-même vérifie (verify) chaque bloc et chaque archive envoyés par Nimbus Backup.

Proxmox VE utilise les mêmes fichiers de clé : une clé créée par Proxmox VE ou par proxmox-backup-client sert aussi à Nimbus Backup. Comment créer la clé, la garder hors du système sauvegardé et la récupérer : la clé de chiffrement de Proxmox Backup Server.

Clé papier et QR code (ajout Nimbus Backup)

• Imprimer la clé au format de proxmox-backup-client key paperkey, avec son QR code, éventuellement protégée par une phrase secrète.
• Importer une clé depuis un QR code scanné, une copie papier ou un texte collé.

Les autres nouveautés

• Plusieurs dossiers sauvegardés en parallèle (#6) : réglage dans l'interface, qui s'applique aussi aux sauvegardes planifiées, ou -parallel N en ligne de commande. Pas de maximum ; nous recommandons le nombre de processeurs divisé par 4. C'est utile quand la relecture domine (disques rapides, peu de données nouvelles) ; à éviter sur un disque dur classique.
• Un seul snapshot VSS pour toute une sauvegarde multi-dossiers, avec une copie par volume : tous les dossiers d'un même volume sont figés au même instant. Avant, chaque dossier avait son propre snapshot, pris à son tour. Si un volume refuse VSS, Nimbus Backup revient automatiquement à un snapshot par dossier. Deux volumes différents (C: et D:) ne sont pas figés au même instant.
• Exclusions dans la ligne de commande proxmoxbackup-directory (#4) : -exclude "*.tmp" (répétable), -exclude-from fichier, ou "exclude" dans la configuration JSON.
• Des sauvegardes de disque restaurables dans Proxmox VE comme une VM fidèle : nombre de processeurs, mémoire, UEFI ou BIOS, type d'OS, cartes réseau avec leurs adresses MAC, identité SMBIOS. En mode VM, le formulaire a son propre champ « ID de VM Proxmox ». La sauvegarde de machine complète reste en beta.

Repris du projet de tizbac :

• un onglet « Tâches en cours » (progression, temps restant, annulation) ;
• le choix du serveur PBS pour chaque tâche ;
• des disques identifiés de façon stable ;
• la restauration des ACL NTFS et POSIX ;
• une suite de tests de bout en bout sur un vrai PBS dans la CI ;
• des recettes de paquets Linux (Debian, Fedora, Arch) dans les sources. Nos releases GitHub ne publient pas de paquets Linux : sous Linux, utilisez le client officiel, que nous réempaquetons dans notre dépôt non officiel proxmox-backup-client.

Le README est traduit en 13 langues, dont 11 par IA ; c'est signalé en tête de chaque fichier.

Corrections, et merci aux rapporteurs

• Un VSS occupé ne supprime plus toutes les copies VSS de la machine. En 0.4.0, quand VSS indiquait qu'une autre copie était en cours de création, le client lançait vssadmin delete shadows /all et redémarrait le service VSS, ce qui détruisait les points de restauration Windows et les snapshots des autres outils. Il attend maintenant et réessaie (30 s, 60 s, 120 s), puis s'arrête avec un message clair.
• Le nettoyage au démarrage ne supprime plus le snapshot d'une autre sauvegarde Nimbus en cours (par exemple une interface lancée pendant une sauvegarde en ligne de commande).
• #9, merci hgreen119-coder : les sauvegardes de disque échouaient toutes à la finalisation, et une tâche planifiée pouvait s'afficher « réussie » sans snapshot sur le PBS.
• #2, merci Kofl : en mode service, l'interface restait sur « Starting backup... » alors que la sauvegarde se faisait.
• #1, merci dead-plant : « Agrandir » ne remplissait pas l'écran.
• Le service ignorait le serveur PBS choisi pour une sauvegarde de dossiers et partait toujours sur le serveur par défaut.
• Les sauvegardes chiffrées faites par proxmox-backup-client (blocs compressés puis chiffrés, son format par défaut) n'étaient pas restaurables. C'est corrigé, et nos blocs chiffrés sont désormais compressés eux aussi.
• Les messages d'erreur donnent la vraie raison renvoyée par PBS, au lieu de « authentication failed » pour tout refus.

Merci aussi à MTkatchouk (#3, #4, #6) et à 346L3 (#5).

Mettre à jour

Le MSI met à jour sur place : même service Windows, configuration conservée. À chaque build, la CI installe le MSI sur une machine Windows, en installation directe et en mise à jour depuis la 0.4.0 publiée, et vérifie le service et les signatures. Si vous venez de la 0.3.0, la migration du dossier de configuration est décrite dans le guide du client Windows.

Le chiffrement ne s'active pas tout seul : choisissez une clé pour chaque serveur. Une fois la clé choisie, la première sauvegarde chiffrée renvoie toutes les données, sans déduplication avec les sauvegardes non chiffrées qui précèdent. Gardez une copie de la clé hors de la machine avant de compter sur ces sauvegardes : sans elle, elles ne se restaurent pas.

Liens

• Release 0.4.1 sur GitHub (exécutable, MSI, outils en ligne de commande, SHA256SUMS.txt)
• CHANGELOG, section 0.4.1
• Clé de chiffrement PBS : créer, sauvegarder, récupérer
• Sauvegarder Windows vers Proxmox Backup Server
• Notre GUI Windows a rejoint le projet de tizbac
• Le projet d'origine, tizbac/proxmoxbackupclient_go

Questions fréquentes