Principe de fonctionnement

FastBCP 1.6 introduit le type de connexion backup_mssql. Le driver ArpeMSBackup lit le fichier .bak sans lancer d’instance SQL Server ni nécessiter d’identifiants. L’utilisateur indique le répertoire contenant le backup (--server), le fichier ou le motif (--database), le schéma et la table source, puis le répertoire de destination et le nom du fichier Parquet. Aucun RESTORE n’est exécuté, ce qui élimine le besoin de disposer d’un espace disque équivalent à la taille de la base.

./FastBCP \
  --connectiontype backup_mssql \
  --server "/var/opt/mssql/backup" \
  --database "tpch_full.bak" \
  --sourceschema "dbo" \
  --sourcetable "orders" \
  --directory "/export/orders" \
  --fileoutput "orders.parquet" \
  --parallelmethod Physical \
  --paralleldegree 8

Performances et parallélisme

Sur un backup complet de 320 Go, l’ouverture initiale du fichier a duré 2 min 29 s ; les ouvertures suivantes n’ont pris que 0,3 s, ce qui montre un cache efficace du format de backup. En activant 24 threads, une table de 175 millions de lignes a été convertie en fichiers Parquet en 29,6 s, soit un débit supérieur à 5 M lignes/s. Le paramètre --parallelmethod Physical découpe la table en autant de tranches que le nombre indiqué par --paralleldegree. Chaque thread lit sa tranche de façon indépendante et génère un fichier orders_chunk_XXX.parquet, ce qui minimise les accès disque concurrentiels.

Limitations et contraintes

FastBCP ne supporte que les sauvegardes full et copy‑only full. Les sauvegardes différentielles, les journaux de transactions et les fichiers ne contenant aucune sauvegarde complète sont rejetés. Les bases chiffrées (TDE ou WITH ENCRYPTION) sont également refusées, car les pages ne peuvent être décryptées sans le certificat serveur. Au niveau de la compression, seuls les algorithmes MS_XPRESS et ZSTD sont pris en charge ; les flux Intel QuickAssist sont exclus. Le lecteur ne rejoue pas le journal de transaction présent dans le backup, ce qui signifie que les pages d’une table modifiée pendant la sauvegarde reflètent l’état au moment de la copie, pas un état transactionnel cohérent.

Scénarios d’utilisation

Le principal cas d’usage est la récupération d’une ou plusieurs tables sans restaurer l’intégralité de la base : lorsqu’une table a été supprimée ou que l’on a besoin d’une version antérieure, FastBCP extrait le tableau en quelques secondes, puis FastTransfer le charge dans une instance SQL Server de n’importe quelle version ou dans PostgreSQL via le protocole COPY. Cette approche supprime la contrainte de version : un backup créé sur SQL Server 2025 peut être chargé dans une instance SQL Server 2019 ou dans un entrepôt de données basé sur PostgreSQL. Pour les migrations, la chaîne FastBCP → Parquet → FastTransfer évite toute charge sur le serveur source, utilise le backup déjà disponible sur un partage réseau, et élimine le besoin d’un serveur de destination temporaire.