En une phrase : PBS sait stocker un datastore entier dans un bucket compatible S3, avec un cache local sur le serveur. C'est la seule façon d'associer PBS et S3 : « copier un datastore vers S3 », c'est synchroniser vers un datastore de ce type.
Statut : aperçu technologique avec PBS 4.0 (6 août 2025), puis « graduated from the technology preview phase » avec PBS 4.2 (29 avril 2026), selon les notes de version officielles.
1. Comment fonctionne un datastore S3
Un datastore S3 a la même structure qu'un datastore sur disque (index, blocs, snapshots), mais ses objets sont écrits dans un bucket, préfixés par le nom du datastore. Plusieurs datastores peuvent donc partager un bucket. Ce que dit la documentation :
- Un cache local est obligatoire. Il garde les index et une partie des blocs pour limiter les requêtes. La documentation recommande 64 à 128 Gio, sur un disque, une partition ou un dataset ZFS dédié avec quota. Un datastore existant ne peut pas servir de cache, et un cache en mémoire seule n'est pas possible.
- PBS ne crée pas le bucket et ne gère pas ses droits : bucket et clé d'accès se préparent chez le fournisseur, avec les droits de lire, écrire, lister et supprimer des objets.
- HTTPS uniquement. Pour un stockage objet auto-hébergé avec un certificat auto-signé, l'empreinte du certificat doit être renseignée.
- Un seul PBS à la fois peut exploiter un datastore. Après la perte du serveur, un PBS neuf peut le reprendre avec les options
reuse-datastoreetoverwrite-in-use, sous le même nom.
proxmox-backup-manager s3 endpoint create mon-s3 \
--access-key '<access-key>' --secret-key '<secret-key>' \
--endpoint '{{bucket}}.s3.{{region}}.amazonaws.com' --region eu-central-1
proxmox-backup-manager datastore create store-s3 /mnt/datastore/store-s3-cache \
--backend type=s3,client=mon-s3,bucket=pbs-bucketLa documentation donne aussi des exemples pour Ceph RADOS Gateway et Cloudflare R2. Certains fournisseurs ont des particularités (adressage par chemin, suppression objet par objet), réglables dans la configuration du point d'accès.
2. Copier un datastore existant vers S3
Il n'y a pas de mode « export vers S3 » à part. On crée un datastore S3, puis un sync job qui y recopie les snapshots du datastore local. Sans --remote, la synchronisation se fait entre deux datastores du même PBS.
proxmox-backup-manager sync-job create copie-s3 \
--store store-s3 --remote-store store-local --schedule daily- Le chiffrement ne se rajoute pas en route. PBS envoie au bucket les blocs tels qu'ils sont stockés ; seul le transport est chiffré (HTTPS). Pour que le fournisseur S3 ne voie que des données chiffrées, chiffrez côté client avec votre propre clé : voir la clé de chiffrement PBS.
- Le snapshot copié arrive non vérifié : la synchronisation ne transporte pas l'état de vérification, c'est au verify job du datastore S3 de le contrôler (voir les verify jobs et la synchronisation). Sur S3, ce contrôle a un coût, détaillé plus bas.
- Pas de bande depuis S3 : le code de PBS 4.2.8 refuse les opérations de sauvegarde sur bande directement depuis un datastore S3 (« direct s3/tape operations are not supported »,
src/tape/mod.rs).
3. Le coût réel : stockage, requêtes, sortie de données
La documentation prévient : « operating as S3 backed object store might cause additional costs. Providers might charge you for storage space and API requests performed to the buckets, egress and bandwidth fees might be charged as well ». Voici ce que chaque tâche de PBS fait sur le bucket :
| Tâche | Ce qu'elle fait sur le bucket |
|---|---|
| Sauvegarde, synchronisation | Un envoi (PUT) par bloc nouveau. Un disque de VM est découpé en blocs de 4 Mio : environ 260 000 blocs par To de données avant compression. |
| Garbage collection | Liste tous les objets du datastore, puis supprime ceux qui ne servent plus. |
| Verify job | Télécharge chaque bloc vérifié (un GET par bloc), sans passer par le cache local (src/backup/verify.rs). |
| Restauration | Télécharge les blocs absents du cache. |
Le poste qui surprend est le verify. Un verify job relit tous les blocs des snapshots qu'il examine, pas seulement les nouveaux. Une VM de 1 To de données sauvegardée chaque nuit, avec un verify quotidien, fait donc télécharger environ 1 To par nuit, soit une trentaine de To par mois.
Calcul sur la grille publiée de Backblaze B2 (relevée le 9 octobre 2026 : 6,95 $ par To et par mois, requêtes courantes gratuites en paiement à l'usage, sortie gratuite jusqu'à 3 fois le volume moyen stocké dans le mois, puis 0,01 $ par Go), pour ce cas : 3 To de sortie gratuits, environ 27 To facturés, soit de l'ordre de 270 $ par mois de vérification. C'est une estimation à partir de la grille, pas une mesure. Elle ne vaut que pour ce fournisseur, et change complètement si l'on espace les vérifications ou si le fournisseur ne facture pas la sortie.
PBS donne de quoi surveiller : les versions 4.1 et 4.2 ont ajouté des limites de débit vers les points d'accès S3, puis des compteurs de requêtes et de trafic par datastore, avec des seuils de notification. Réglez-les avant la première facture, pas après.
4. Immuabilité : Object Lock n'est pas pris en charge
C'est la question la plus posée, et la réponse de l'équipe Proxmox est constante :
- août 2025 : « object locking is currently not part of the PBS S3 implementation feature set » (forum Proxmox) ;
- janvier 2026 : « immutable objects are currently not supported by the PBS S3 implementation », et « Garbage collection must be handled by the PBS, not by retention settings of the S3 backend » (forum Proxmox).
La demande est ouverte dans le ticket 6780, assignée mais pas livrée au 9 octobre 2026. La raison tient à la déduplication : un même bloc sert à de nombreux snapshots, et c'est PBS qui décide quand il peut disparaître. Un verrou posé côté bucket empêche les suppressions que PBS demande (garbage collection, suppression de snapshots) ; une règle d'expiration côté bucket peut au contraire effacer un bloc encore utilisé par un snapshot récent, qui devient alors illisible.
Un datastore S3 est donc une copie en ligne, joignable avec les clés du PBS. Contre un attaquant qui obtient ces clés, la protection qui ne dépend d'aucun réglage reste une copie hors ligne : voir sauvegarde immuable et ransomware.
5. Quand un PBS hébergé est plus simple
Le datastore S3 a de vrais atouts : il réutilise un stockage objet que vous avez peut-être déjà, il grandit sans changer de disques, et il évite de gérer un second serveur. Il est intéressant si vous avez déjà un PBS, un fournisseur S3 qui ne facture ni la sortie ni les requêtes, et peu de restaurations.
Un PBS hébergé est plus simple dans les autres cas, et c'est ce que nous vendons, à lire avec ce biais :
- vous réservez des To, sans facture de requêtes ni de sortie de données ; la vérification relit nos disques, pas un bucket facturé ;
- pas de cache local à dimensionner chez vous : vos PVE sauvegardent directement vers un PBS ;
- une copie hors ligne sur disques débranchés existe, avec l'offre AirGapped Drive dès 34 € HT par To et par mois.
6. Et l'entrée S3 de la Nimbus Backup Gateway ?
C'est l'inverse du datastore S3 : ici, S3 est la porte d'entrée, pas le stockage. Des outils qui ne parlent pas à PBS (restic, rclone, Synology Hyper Backup, scripts de bases de données) écrivent en S3 vers la Gateway, et ce qu'elle reçoit est ensuite sauvegardé vers PBS. Les VM Proxmox, elles, vont directement de Proxmox VE à PBS. Détails sur la sauvegarde S3 externalisée vers PBS.
Questions fréquentes
Proxmox Backup Server prend-il en charge le stockage S3 ?
Oui. Le datastore sur stockage objet compatible S3 est arrivé en aperçu technologique avec PBS 4.0 (6 août 2025) et il est officiellement pris en charge depuis PBS 4.2 (29 avril 2026). Il exige un cache local sur le serveur PBS, de 64 à 128 Gio recommandés par la documentation.
Peut-on rendre immuable un datastore PBS sur S3 avec Object Lock ?
Non, pas aujourd'hui. Un membre de l'équipe Proxmox l'a écrit sur le forum en août 2025 puis en janvier 2026 : les objets immuables ne sont pas pris en charge par l'implémentation S3 de PBS, et la libération de place doit être faite par PBS, pas par des règles de rétention du bucket. La demande est suivie dans le ticket 6780. Un verrou ou une règle d'expiration posés côté bucket entrent en conflit avec les suppressions que PBS fait lui-même.
Sources : Forum Proxmox, août 2025 · Forum Proxmox, janvier 2026 · Ticket Proxmox 6780
Un verify job sur un datastore S3 coûte-t-il de l'egress ?
Oui. Pour vérifier un bloc, PBS le télécharge depuis le bucket (une requête GET par bloc), sans passer par le cache local. Un verify job relit tous les blocs des snapshots qu'il examine : chez un fournisseur qui facture la sortie de données ou les requêtes, la vérification se paie.
Sources : Code de PBS, verify.rs
Un PBS hébergé, sans facture de requêtes
NimbusBackup héberge des Proxmox Backup Server managés : vous réservez des To, la vérification et le garbage collection tournent sur nos disques, et la copie hors ligne est disponible. À partir de 12 € HT par To et par mois.