FastBCP 1.6: de backup SQL Server a Parquet sin restaurar

Que es FastBCP 1.6 y que cambia para tu equipo de datos

FastBCP 1.6 exporta una tabla directamente desde un backup completo de SQL Server a Parquet: sin restaurar la base, sin levantar una instancia de SQL Server y sin credenciales que administrar. En una prueba sobre un backup de produccion de 320 GB, la primera apertura del archivo tardo 2 minutos 29 segundos y las siguientes 0,3 segundos. Con 24 hilos, una tabla de 175 millones de filas llego a Parquet en 29,6 segundos.

La herramienta es de Arpe, la misma casa del driver ArpeMSSQL, y el movimiento es interesante para cualquier equipo con poca infraestructura: el backup que ya esta guardado en un share se convierte en datos consultables sin tocar produccion. No hay replica de lectura, ni ventana de extraccion, ni locks sobre tablas ocupadas.

Como se exporta una tabla de un backup de SQL Server a Parquet

El tipo de conexion nuevo se llama backup_mssql. Detras esta el driver ArpeMSBackup, que abre el archivo .bak como un archivo binario plano: entiende el formato lo suficiente para ir directo a los datos de la tabla pedida y saltar todo lo demas. Los valores se decodifican a columnas de Apache Arrow, que FastBCP escribe a Parquet.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Los parametros clave:

--server: el directorio donde viven los backups
--database: el archivo .bak o un patron que lo encuentre (tpch_*.bak para un backup striped, o los stripes listados y separados por punto y coma)
--sourceschema y --sourcetable: la tabla a exportar
--parallelmethod Physical con --paralleldegree: corta la tabla en tantas rebanadas como grado de paralelismo y genera un Parquet por chunk

La primera exportacion paga un costo unico: el archivo completo se lee una vez, descomprimido si hace falta, para que el driver se oriente dentro de el. FastBCP guarda lo aprendido en una cache local y las siguientes exportaciones del mismo backup, sea cual sea la tabla, arrancan en 0,3 segundos. Un backup nuevo vuelve a pagar la apertura.

Para exportar un subconjunto de columnas se usa --query con una lista: SELECT o_orderkey, o_orderdate FROM dbo.orders. Esa es toda la gramatica: SELECT * o lista de columnas, FROM [schema.]tabla. No acepta WHERE.

Que tan rapido es: los numeros reales

Los datos de produccion son los mas elocuentes. Sobre un backup nocturno de 320 GB repartido en 16 archivos de 20 GB, con dos tablas columnstore de mas de 100 millones de filas, FastBCP 1.6.3 con 24 hilos escribio Parquet con Zstd:

Tabla de 220,9 millones de filas y 124 columnas: 71,8 segundos en caliente, a 3,07 millones de filas por segundo (381 millones de celdas por segundo).
La misma tabla exportada en vivo desde la instancia de SQL Server 2022: 155,9 segundos. Es decir, 2,2 veces mas rapido desde el backup, y con SQL Server sin hacer ningun trabajo.
La tabla de 175,1 millones de filas y 62 columnas tardo 179,1 segundos en frio, de los cuales 148,6 fueron la apertura del backup. Descontada esa apertura, la exportacion en si tomo 29,6 segundos.

En un portatil con TPC-H SF10 (i9-13950HX, 64 GB de RAM, NVMe, Windows 11), las tablas de 15 millones de filas se exportaron en 1,5 a 2 segundos desde cualquiera de los tres formatos de backup probados: sin comprimir, ZSTD y MS_XPRESS. Eso es 2,3 a 2,4 veces la velocidad de exportar en vivo con el driver adbc_mssql y 5,4 a 5,8 veces la de mssql. La tabla columnstore llego a unos 149 millones de celdas por segundo, 60 millones de filas en 6,4 segundos.

Dos matices que importan: una vez abierto el backup, la compresion cuesta poco (ZSTD queda dentro del 5% del backup sin comprimir), y las aperturas en frio posteriores a la primera bajan a 20-30 milisegundos. La velocidad final depende de dos cosas: que tan rapido lee tu disco y que tan rapido decodifica la herramienta. Un NVMe local entrega varios GB/s; un disco de nube pequeno, cuyo throughput esta atado a su tamano, sera el cuello de botella.

Que restricciones tiene leer un .bak sin restaurarlo

Antes de meter esto en un runbook, conviene tener claras las limitaciones:

Solo backups full y copy-only full. Los diferenciales y los de log no se aplican.
Un archivo que no contenga un backup full es rechazado.
Los backups de bases con TDE y los cifrados con WITH ENCRYPTION se rechazan: sus paginas no se pueden leer sin el certificado del servidor.
Compresion Intel QuickAssist no soportada. MS_XPRESS y ZSTD si.
Disponible en Windows x64 y Linux x64.
Parquet es la unica salida por ahora.
No hay replay del log de transacciones. Un RESTORE reproduce la parte del log incluida en el backup para dejar la base consistente; FastBCP no. Si una tabla se estaba escribiendo durante el backup, obtienes sus paginas tal como se copiaron. Para una imagen exacta, respalda con la tabla quieta.

Sobre memoria, el comportamiento cambia segun el tipo de tabla. Una tabla rowstore de 15 millones de filas con 8 hilos llego a 674 MB de pico desde un backup sin comprimir y 979 MB desde uno ZSTD. Las columnstore son el punto debil: un rowgroup de hasta un millon de filas se decodifica entero, asi que la memoria crece con los hilos y las columnas. Con 24 hilos, 1.6.3 llego a 26 GB con 62 columnas y 44 GB con 124, contra 4,5 GB de la exportacion en vivo. La version 1.6.5 acota ese consumo: una tabla columnstore ancha con 8 hilos paso de 42 GB a 5,9 GB.

Que significa esto para tu startup

Primero, revisa que backups ya tienes antes de comprar infraestructura. La mayoria de las bases de produccion se respaldan cada noche y esos archivos ya viven fuera de produccion. Si necesitas alimentar un data lake o un warehouse, exportar desde el backup evita abrir conexiones al servidor, montar una replica de lectura o negociar una ventana de extraccion con el equipo de aplicaciones. La accion concreta: toma tu backup mas reciente, exporta una tabla mediana y mide cuanto tarda la apertura en frio. Ese numero decide si el flujo es viable para tu volumen.

Segundo, si tu migracion va de una version nueva a una vieja, Parquet elimina la restriccion. Microsoft no permite restaurar un backup en una version anterior a la que lo creo. Redmond Magazine documento que el camino oficial es exportar e importar un Data-Tier Application, un proceso que el propio medio describe como lento en bases grandes y que ademas no migra objetos como los jobs de SQL Agent, los logins o ciertos objetos CLR. Con FastBCP exportas la tabla a Parquet y FastTransfer la carga en la instancia que quieras, incluso en una version mas antigua, o en PostgreSQL via su protocolo COPY.

Tercero, dimensiona la memoria antes de paralelizar. Si tus tablas son columnstore, el grado de paralelismo es directamente proporcional al pico de RAM. En una maquina modesta, baja --paralleldegree o sube a 1.6.5 antes de correr 24 hilos.

Casos de uso: restore de una tabla, migraciones y data lake

El caso mas comun es el restore de n tablas: alguien borro una tabla o necesita la version del martes pasado. La respuesta habitual es restaurar la base completa al lado de produccion, lo que exige tanto disco libre como la base y horas de restore en un backup de varios terabytes, todo para recuperar una sola tabla. Con este flujo exportas esa tabla del backup y la cargas donde quieras: una base de scratch, el servidor de produccion bajo otro nombre o una instancia de version anterior. La carga usa FastTransfer, un chunk por archivo Parquet, y la tabla destino debe existir de antemano.

En migraciones, el copiado masivo inicial puede salir del backup de la noche anterior, sin cargar el servidor origen. Y en el cutover final el mismo camino sirve: se detiene la aplicacion, se toma un backup full COPY_ONLY, se exporta y se carga. Con la aplicacion detenida el backup es consistente y no hace falta replay del log. Si eso supera a una transferencia directa depende del tamano de la base y de la ventana de cutover, asi que conviene medir ambos caminos.

Vale la pena contrastarlo con las alternativas administradas. El blog de Google Cloud describe que en Cloud SQL el shrink nativo de disco exige un downtime proporcional al tamano total asignado, lo que en discos de varios terabytes significa horas de mantenimiento offline, y que su Database Migration Service replica con un backup full inicial mas backups de log continuos. La propuesta de leer el .bak directamente es distinta: no hay instancia destino corriendo durante la extraccion, y el formato de salida es un archivo abierto que cualquier motor puede leer.