POC Backup S3 Scaleway — Veeam vs Plakar¶
Rapport comparatif¶
Date : Mai 2026
Durée du test : 7 jours (6 – 13 mai 2026)
Environnement : Scaleway — Région nl-ams
Tickets Jira : INF-121 · INF-113
1. Contexte et objectifs¶
Ce POC a pour objectif d'évaluer deux solutions de backup pour protéger des données stockées dans des buckets S3 Scaleway Object Storage :
- Veeam Backup & Replication (v12, Data Platform Premium Edition) — solution commerciale
- Plakar (v1.1.0-rc.1) — solution open source émergente, membre de la Linux Foundation / CNCF
Le cas d'usage testé est le backup d'un bucket S3 source vers un bucket S3 destination, avec restauration complète dans un troisième bucket, simulant un scénario de disaster recovery.
2. Architecture de test¶
┌──────────────────────────────────────┐
│ Instance Debian BASIC3-X4C-8G │
│ (4 vCPU, 8 Go RAM, Debian 12) │
│ │ ┌─────────────────────────┐
│ ┌──────────────────┐ │ │ poc-veeam-fake-app │
│ │ XML Generator │──── upload ──────────▶ │ (bucket source) │
│ │ Python/boto3 │ │ │ 325 550 objets │
│ └──────────────────┘ │ │ 192,43 Go │
│ │ └───────────┬─────────────┘
│ ┌──────────────────┐ │ │
│ │ Plakar v1.1.0-rc1 │──── backup ──────────▶ poc-plakar-destination
│ └──────────────────┘ │ (40,86 Go - 2 034 objets)
└──────────────────────────────────────┘
│
┌──────────────────────────────────────┐ │
│ Bare Metal EM-A610R-NVME │ │
│ (AMD Ryzen PRO 3600, 32 Go RAM) │ │
│ (2x1 To NVMe, Windows Server 2022) │ │
│ │ │
│ ┌──────────────────┐ │ │
│ │ Veeam B&R Premium │──── backup ──────────▶ poc-veeam-destination
│ └──────────────────┘ │ (42,12 Go - 2 511 objets)
└──────────────────────────────────────┘
3. Méthodologie¶
3.1 Générateur de données¶
Une application Python a été développée pour simuler un flux continu d'écriture dans le bucket source. Elle génère des fichiers XML contenant des données aléatoires (factures, commandes, personnes) et les upload via l'API S3.
- Rythme : ~20 000 fichiers toutes les 6 heures (100 fichiers par batch, toutes les 108 secondes)
- Taille des fichiers : 5 Ko à 500 Ko (10 à 500 enregistrements XML par fichier)
- Volume quotidien : ~80 000 fichiers, ~8 Go/jour
- Volume total en fin de test : 325 550 objets, 192,43 Go
3.2 Planification des backups¶
Les deux solutions ont été configurées avec un backup toutes les 6 heures (0h, 6h, 12h, 18h UTC) pour comparer leur comportement dans des conditions identiques.
4. Résultats Veeam¶
4.1 Backup¶
| Métrique | Valeur |
|---|---|
| Premier backup (full) | 2 minutes (5/6 17:01 → 17:03) |
| Backups incrémentaux | 25 à 49 minutes |
| Nombre total de sessions réussies | 27 sur 31 |
| Sessions en échec | 4 (11 mai — conflit avec un restore en cours) |
Le premier backup full a été remarquablement rapide (2 min). Les incrémentaux se sont stabilisés entre 25 et 49 minutes, avec une légère augmentation à mesure que le volume source croissait. La durée est restée prévisible et constante.
Les 4 échecs du 11 mai sont dus à un conflit de verrouillage (Item is locked by running session [NasRestore]) : un restore était en cours pendant que le job de backup tentait de s'exécuter. Après résolution du verrou, les backups ont repris normalement avec des retries automatiques.
4.2 Restore¶
Le restore a été réalisé en deux sessions :
| Session | Date | Objets | Volume | Durée |
|---|---|---|---|---|
| Restore 1 | 11/05 (11:08 → 17:15) | 245 250 | 134,9 Go | 6h01m |
| Restore 2 | 13/05 (09:22 → 11:15) | 80 300 | 44,3 Go | 1h46m |
| Total | — | 325 550 | 192,43 Go | ~7h48m |
Le premier restore a couvert 75% des données en 6h. Le second a restauré les 25% restants en 1h46. Les deux sessions se sont terminées avec succès, et le bucket de destination contient exactement le même nombre d'objets et la même taille que la source.
Le fait que le restore ait été découpé en deux sessions est lié au conflit de verrouillage du 11 mai : le restore en cours a bloqué les backups planifiés, ce qui a nécessité de relancer un second restore pour les objets créés entre-temps.
4.3 Stockage consommé¶
| Bucket | Objets | Taille |
|---|---|---|
| Source (poc-veeam-fake-app) | 325 550 | 192,43 Go |
| Backup (poc-veeam-destination) | 2 511 | 42,12 Go |
| Ratio de compression | — | ~4,6:1 |
Veeam a compressé et dédupliqué 192 Go de données source en 42 Go de stockage backup, soit un ratio de compression/déduplication d'environ 4,6:1.
4.4 Problème identifié — Fichier de 43 Go¶
Lors d'un test de restore sur un autre bucket source contenant un fichier de 43 Go (demarches_fichiers.zip), le restore a échoué avec l'erreur AmazonS3RestApiWriteStream Stream is broken.
Cause identifiée : Scaleway Object Storage limite les multipart uploads à 1 000 parts. Veeam utilise des parts de 33,55 Mo (constaté dans la console Scaleway). Pour un fichier de 43 Go, cela nécessite ~1 281 parts, dépassant la limite de 1 000. Le stream se rompt à la part 1 001.
Statut : un ticket est ouvert auprès du support Veeam, en attente de retour. Une clé de registre pour ajuster la taille des parts serait nécessaire mais n'est pas documentée publiquement.
5. Résultats Plakar¶
5.1 Backup¶
| Métrique | Valeur |
|---|---|
| Premier backup | 1 min (140 Mo source) |
| Backups incrémentaux | 50 min à 1h17 |
| Données écrites par backup | 1,6 à 1,8 Go |
| Nombre total de sessions réussies | 24 sur 25 |
Plakar a montré une excellente capacité de déduplication : pour un volume source de 179 Go, chaque backup incrémental n'écrit que 1,6 à 1,8 Go de données nouvelles vers le bucket de backup.
La durée des backups est restée stable autour de 1h tout au long du test, indépendamment de la croissance du volume source (de 7 Go à 179 Go). Cela confirme que Plakar traite efficacement les incréments et ne rescanne pas l'intégralité des données à chaque run.
La mise à jour vers v1.1.0-rc.1 a été effectuée le 11 mai à 11h30. Elle n'a pas eu d'impact notable sur les performances de backup. Les deux derniers backups (13/05 00h : 7m59, 13/05 06h : 7m50) sont rapides uniquement parce que le générateur de fichiers avait été arrêté et qu'il n'y avait quasiment plus de nouvelles données à traiter (167 Mo puis 58 Ko écrits).
Le backup du 12/05 à 18h00 a été anormalement long (5h41) suite à une session interrompue à 15h16, nécessitant une reconstruction du cache interne.
Chaque session de backup se termine par un warning non bloquant (could not close store: transport: failed to write client preface) lié à la librairie gRPC. Ce warning n'impacte pas l'intégrité des backups.
5.2 Restore¶
| Métrique | Valeur |
|---|---|
| Durée estimée du restore complet (S3 → S3) | ~24h+ (multiples tentatives) |
| Objets restaurés | 325 550 |
| Volume restauré | 192,43 Go |
| Intégrité | 100% (identique à la source) |
Le restore a été l'aspect le plus problématique de Plakar lors de ce POC. Plusieurs difficultés ont été rencontrées :
- Performance : le restore S3 vers S3 est très lent, avec un ETA affiché de 16 à 17h. La double traversée réseau (lire depuis le store, décrypter/reconstruire, réécrire vers la destination) explique cette lenteur.
- Absence de reprise : chaque interruption (volontaire ou crash) oblige à recommencer le restore depuis le début. Aucune option de skip des fichiers déjà restaurés n'est disponible.
- Crashes multiples : des erreurs de type
EOF,context canceled, et des dumps de données binaires/uint8 dans les logs ont provoqué des arrêts inattendus. - Impact de la concurrence : l'augmentation du paramètre
-concurrency(de 33 à 64 ou 128) n'a pas amélioré les performances de restore.
Le restore a finalement abouti après plusieurs tentatives sur environ 24h+ cumulées, avec un résultat intègre (325 550 objets, 192,43 Go identiques à la source).
Test complémentaire : restore vers stockage local¶
Un test de restore vers le système de fichiers local a été réalisé pour isoler la cause des mauvaises performances S3 → S3.
$ time plakar at @backup-plakar restore -to /home/backuptest/restore-local fcc365bc
[40:07] fcc365bc generated/2026/05/08/batch-00432/fb54dedbdf69.xml 32 GiB
export: nodes=594/594, objects=57350/57350
store: read=6.5 GiB, write=0 B
real 40m14.263s
| Métrique | Valeur |
|---|---|
| Snapshot restauré | fcc365bc (08/05 00:00 — 32 Go source) |
| Destination | Système de fichiers local |
| Objets restaurés | 57 350 |
| Durée | 40 minutes |
Le restore local du snapshot de 32 Go s'est effectué en 40 minutes, sans crash ni interruption. Ce résultat confirme que le pipeline de lecture/déchiffrement/reconstruction de Plakar est performant : le bottleneck identifié lors du restore S3 → S3 est la réécriture vers le bucket de destination, pas le traitement des données.
5.3 Stockage consommé¶
| Bucket | Objets | Taille |
|---|---|---|
| Source (poc-veeam-fake-app) | 325 550 | 192,43 Go |
| Backup (poc-plakar-destination) | 2 034 | 40,86 Go |
| Ratio de compression | — | ~4,7:1 |
Plakar offre un ratio de compression/déduplication légèrement supérieur à Veeam (4,7:1 vs 4,6:1), avec 25 snapshots conservés pour 40,86 Go de stockage total.
6. Tableau comparatif¶
| Critère | Veeam | Plakar |
|---|---|---|
| Premier backup (full) | 2 min | 1 min |
| Backup incrémental | 25 – 49 min | ~1h (stable) |
| Restore complet (S3 → S3) | ~7h48 (2 sessions) | ~24h+ (multiples tentatives) |
| Reprise de restore | Oui | Non |
| Stockage backup | 42,12 Go | 40,86 Go |
| Ratio compression/dédup | 4,6:1 | 4,7:1 |
| Fiabilité backup | 27/31 (87%) | 24/25 (96%) |
| Fiabilité restore | Succès au 1er essai | Succès après multiples tentatives |
| Chiffrement | Non natif (dépend du stockage) | Oui (end-to-end, passphrase) |
| Interface | Console graphique complète | CLI + interface web (plakar ui) |
| Compatibilité S3 | Mature (limitation identifiée sur gros objets > 33 Go) | Fonctionnelle |
| Licence | Commerciale (~payant/an) | Open source (gratuit) |
| Maturité | Production | Beta (v1.1.0-rc.1) |
| Infrastructure requise | Bare metal Windows | Instance Linux légère |
7. Limitations identifiées¶
7.1 Scaleway Object Storage¶
- Limite de 1 000 parts par multipart upload : impacte les deux solutions pour les fichiers unitaires de plus de ~5 Go (avec des parts de 5 Mo). Veeam utilise des parts de 33,55 Mo, ce qui limite les fichiers à ~33 Go maximum. Contrairement à AWS (10 000 parts), cette limite Scaleway nécessite des ajustements côté client.
7.2 Veeam¶
- Pas de paramétrage de la taille des parts depuis l'interface graphique : les ajustements S3 nécessitent des clés de registre Windows non documentées officiellement.
- Conflit de verrouillage : un restore en cours bloque les backups suivants.
- Coût d'infrastructure : nécessite un serveur Windows dédié (bare metal ou VM) avec licence Windows Server et licence Veeam.
7.3 Plakar¶
- Performance de restore S3 → S3 : environ 3 fois plus lent que Veeam pour un volume identique, avec une fiabilité nettement inférieure (multiples crashes, pas de reprise).
- Absence de reprise de restore : tout crash oblige à recommencer depuis le début.
- Stabilité : crashes aléatoires lors de restores longs, messages d'erreur cryptiques (dumps binaires uint8).
- Version beta : l'intégration S3 et les plugins nécessitent une installation manuelle (
plakar pkg add s3) et peuvent être perdus lors des mises à jour.
8. Analyse des coûts¶
Infrastructure mensuelle (estimation)¶
| Composant | Veeam | Plakar |
|---|---|---|
| Serveur | Bare metal EM-A610R-NVME (~120€/mois) | Instance BASIC3-X4C-8G (~30€/mois) |
| Licence OS | Windows Server 2022 (inclus) | Debian (gratuit) |
| Licence logicielle | Veeam (évaluation → payant) | Gratuit (open source) |
| Stockage backup S3 | 42 Go × tarif Scaleway | 41 Go × tarif Scaleway |
| Total infra (hors licence Veeam) | ~120€/mois | ~30€/mois |
Le stockage S3 consommé par les backups est quasi identique entre les deux solutions (~41–42 Go). La différence principale réside dans le coût du serveur de backup et de la licence Veeam.
Annexes¶
A. Détail des sessions de backup Plakar¶
| Date | Snapshot | Taille source | Durée | Données écrites |
|---|---|---|---|---|
| 06/05 14:49 | 2cd444b2 | 140 Mo | 1m01s | — |
| 07/05 06:39 | 6bca8fb5 | 7,7 Go | 56m42s | 1,6 Go |
| 07/05 12:00 | 77b261ef | 14 Go | 50m40s | 1,4 Go |
| 07/05 18:00 | 7cadba37 | 23 Go | 1h05m | 1,8 Go |
| 08/05 00:00 | fcc365bc | 32 Go | 1h14m | 1,7 Go |
| 08/05 06:00 | b3fbbe60 | 40 Go | 1h02m | 1,7 Go |
| 08/05 12:00 | bf3f3ac8 | 48 Go | 1h02m | 1,7 Go |
| 08/05 18:00 | 9440d46d | 56 Go | 1h02m | 1,7 Go |
| 09/05 00:00 | 1def6b2d | 64 Go | 1h10m | 1,8 Go |
| 09/05 06:00 | 41ecd4fa | 72 Go | 1h01m | 1,7 Go |
| 09/05 12:00 | a966b990 | 81 Go | 1h01m | 1,7 Go |
| 09/05 18:00 | fa8a23bd | 89 Go | 1h02m | 1,8 Go |
| 10/05 00:00 | 2b5ebee6 | 97 Go | 1h09m | 1,8 Go |
| 10/05 06:00 | 16d5ed82 | 105 Go | 1h02m | 1,7 Go |
| 10/05 12:00 | 09101a5f | 114 Go | 1h05m | 1,8 Go |
| 10/05 18:00 | 0ee3479f | 122 Go | 1h03m | 1,7 Go |
| 11/05 00:00 | 214f84a3 | 131 Go | 1h12m | 1,8 Go |
| 11/05 06:00 | cc3e5eae | 138 Go | 1h01m | 1,6 Go |
| 11/05 11:30 | — Mise à jour vers v1.1.0-rc.1 — | |||
| 11/05 12:00 | 64d0210d | 146 Go | 1h00m | 1,7 Go |
| 11/05 18:00 | 1c7c4dda | 154 Go | 1h03m | 1,7 Go |
| 12/05 00:00 | a3e024cd | 163 Go | 1h16m | 1,8 Go |
| 12/05 06:00 | 84aa5104 | 171 Go | 1h09m | 1,7 Go |
| 12/05 18:00 | 6d4a4ae2 | 179 Go | 5h41m | 1,8 Go |
| 13/05 00:00 | 8279fa1c | 179 Go | 7m59s | 167 Mo |
| 13/05 06:00 | 02166770 | 179 Go | 7m50s | 58 Ko |
B. Détail des sessions de backup Veeam¶
| Date | Type | Durée | Statut |
|---|---|---|---|
| 06/05 17:01 | Full | 2 min | Succès |
| 07/05 02:00 | Incrémental | 15 min | Succès |
| 07/05 12:00 | Incrémental | 25 min | Succès |
| 07/05 18:00 | Incrémental | 31 min | Succès |
| 08/05 00:00 | Incrémental | 29 min | Succès |
| 08/05 06:00 | Incrémental | 32 min | Succès |
| 08/05 12:00 | Incrémental | 32 min | Succès |
| 08/05 18:00 | Incrémental | 32 min | Succès |
| 09/05 00:00 | Incrémental | 33 min | Succès |
| 09/05 06:00 | Incrémental | 32 min | Succès |
| 09/05 12:00 | Incrémental | 34 min | Succès |
| 09/05 18:00 | Incrémental | 36 min | Succès |
| 10/05 00:00 | Incrémental | 36 min | Succès |
| 10/05 06:00 | Incrémental | 41 min | Succès |
| 10/05 12:00 | Incrémental | 40 min | Succès |
| 10/05 18:00 | Incrémental | 43 min | Succès |
| 11/05 00:00 | Incrémental | 41 min | Succès |
| 11/05 06:00 | Incrémental | 47 min | Succès |
| 11/05 12:00 | Incrémental | — | Échec (verrou restore) |
| 11/05 12:59 | Retry 1 | 5 min | Échec |
| 11/05 13:14 | Retry 2 | 8 min | Échec |
| 11/05 13:32 | Retry 3 | 6 min | Échec |
| 11/05 18:00 | Incrémental | 47 min | Succès |
| 12/05 00:00 | Incrémental | 47 min | Succès |
| 12/05 06:00 | Incrémental | 49 min | Succès |
| 12/05 12:00 | Incrémental | 47 min | Succès |
| 12/05 14:39 | Incrémental | 38 min | Succès |
| 12/05 18:00 | Incrémental | 27 min | Succès |
| 13/05 00:00 | Incrémental | 31 min | Succès |
| 13/05 06:00 | Incrémental | 30 min | Succès |