|

dbclone: cloná staging a tu laptop sin instalar clientes

En pocas palabras: dbclone, una CLI en Go con licencia MIT publicada el 7/10/2026, clona MongoDB y MySQL de staging a tu laptop sin instalar clientes: ejecuta las herramientas de dump y restore con docker exec dentro de tus contenedores Docker y las une por pipe, sin archivos intermedios.

Para clonar una base de datos de staging a tu laptop sin instalar clientes, phuthuycoding publicó el 7/10/2026 dbclone, una CLI en Go con licencia MIT. Ejecuta las herramientas de dump y restore de MongoDB y MySQL dentro de tus contenedores Docker y las une por pipe, sin archivos intermedios.

dbclone es una herramienta de línea de comandos escrita en Go que clona bases de MongoDB y MySQL entre dos conexiones cualquiera (staging a local, prod a local, local a staging o staging a otro servidor), completas o con las tablas y colecciones que elijas. Usa las herramientas que ya traen las imágenes oficiales mongo y mysql, y suma transmisión en paralelo, reintentos y progreso en vivo en la terminal. Es un proyecto de un solo autor, no un producto de un vendor.

En este artículo:

En 30 segundos

  • dbclone no instala nada en el host: hace docker exec en tus contenedores mongo y mysql locales.
  • Cada dump va por pipe directo a su restore, sin archivo en disco. Las colecciones de MongoDB de 64 MiB o más tienen su propio stream.
  • Cada stream se reintenta 3 veces con backoff. Para escribir en algo que no sea local tenés que tipear el nombre del destino.
  • La copia de MySQL no es un punto en el tiempo consistente entre tablas. El autor aclara que no es una herramienta de backup.
  • Instalación: go install github.com/phuthuycoding/dbclone@latest, Homebrew, Scoop o binario de GitHub Releases.

¿Cómo funciona dbclone con docker exec en los contenedores locales?

Las imágenes oficiales mongo y mysql ya incluyen mongodump, mongorestore, mysqldump y mysql. Según el post del autor en dev.to, dbclone no instala nada en tu máquina: cada dump y cada restore es un docker exec dentro del contenedor que ya tenés corriendo.

El autor cuenta dos consecuencias que no había planeado. La primera: desaparece el desfasaje de versiones, porque el cliente que hace el dump es de la misma versión mayor que el servidor que restaura (son la misma imagen). La segunda: cualquier dirección funciona, porque el contenedor es solo la tubería. Tus contenedores locales son un perfil integrado llamado local.

Cualquiera que haya armado un entorno así conoce el procedimiento de wiki: instalás la versión correcta de mongodump, instalás el cliente de MySQL, corrés cuatro comandos, esperás, cruzás los dedos para que la sesión SSH no se caiga a mitad de un restore de 3 GB y, si se cae, arrancás de nuevo con la sensación de haber perdido la tarde. Ese procedimiento es justo lo que el autor dice haber reemplazado. Complementá con errores de CI guardados en una base consultable.

Eso sí: la idea depende de que uses las imágenes oficiales con las credenciales root en el entorno del contenedor.

¿Cómo copia los datos sin generar archivos de dump en disco?

clonar base de datos diagrama explicativo

dbclone conecta cada dump con su restore por pipe, así que no hay archivo intermedio, ni error de disco lleno ni paso de limpieza. El trabajo grande tiene su propio stream y todos los streams comparten un pool de slots que se despacha de mayor a menor.

  • MongoDB: una colección de 64 MiB o más es un pipe mongodump --collection | mongorestore. Todo lo más chico viaja junto en un stream extra.
  • MySQL: las tablas se reparten en hasta -w grupos balanceados por tamaño (4 por defecto), cada uno con mysqldump --single-transaction | mysql. Triggers, vistas, rutinas y eventos entran después de los datos.
  • Pool global: -j define los slots concurrentes (8 por defecto) para todas las bases. Un slot que libera una base chica pasa directo a una grande.

Así se ve la corrida en el README del repositorio:

Cloning 3 databases prod → local · pool 8 streams · max 4 streams/db
⠹ mongo:shop orders ⇉2 [==========>-------------] 42% 1.2 GiB / ~2.9 GiB 18.4 MiB/s 01:07
✓ mysql:app done [========================] 100% 235.6 MiB 57.2 MiB/s 00:04
· mysql:crm waiting for slot [------------------------] 0% 0.0 b / ~80.0 MiB

Ojo: es una salida de ejemplo del README, no un benchmark. Las velocidades dependen de tu red, tu disco y tu servidor de origen.

¿Qué pasa si se corta la conexión y cómo evita pisar staging por error?

Cada stream se reintenta tres veces con backoff, y como el restore borra y recrea el objeto, el reintento arranca limpio en vez de agregar filas a una tabla a medio escribir. Los errores que ningún reintento arregla, como access denied, fallan de inmediato. Para escribir en un servidor remoto, dbclone exige tipear el nombre del destino. Tema relacionado: la trampa del pool de conexiones en Kubernetes.

Las protecciones que describe el autor:

  • Confirmación explícita: escribir en cualquier destino que no sea local requiere tipear su nombre, de forma interactiva o con -confirm staging.
  • -fresh acotado: borrar bases enteras antes de copiar solo funciona con destino local.
  • Sin autoclonado: un servidor nunca se clona sobre sí mismo.
  • Secretos: las contraseñas llegan a las herramientas como variables de entorno, los perfiles tienen modo 0600 y los logs se limpian de user:password@.

Todo esto es la descripción del propio autor. No encontré una auditoría independiente, así que tomalo con pinzas hasta que lo pruebes en tu entorno.

¿Sirve dbclone como herramienta de backup?

No. Cada grupo de tablas MySQL toma su propio snapshot con --single-transaction, por lo que la copia no es un punto en el tiempo consistente entre tablas. Sirve para datos de desarrollo. Para recuperación ante desastres o auditorías necesitás otra cosa.

El autor lo dice sin vueltas: es una herramienta para datos de desarrollo y no la usaría como backup (traducción nuestra de su post). Me gusta que ponga el límite a la vista y no lo esconda al final del README.

Una advertencia que es mía y no del autor: que sea cómodo copiar staging a una laptop no autoriza a llevarse datos personales sin anonimizar. Si tu staging tiene datos reales de clientes, resolvé eso antes de clonar. Relacionado: un dashboard único para tus bases multi-cloud.

¿Cómo instalar y probar dbclone para clonar una base de datos paso a paso?

Necesitás Docker con MongoDB y MySQL locales corriendo desde las imágenes oficiales, y que el servidor remoto sea alcanzable desde adentro de los contenedores. Instalás con go install github.com/phuthuycoding/dbclone@latest o con un binario de Releases, y corrés dbclone -check antes de nada. Según el README, también hay Homebrew y Scoop.

go install github.com/phuthuycoding/dbclone@latest
dbclone -check
dbclone
dbclone -from staging -only mongo:shop,mysql:app -yes
  • dbclone -check: valida Docker y los contenedores, y si falta algo imprime el comando para arreglarlo.
  • dbclone sin argumentos: en la primera corrida crea un perfil y te deja elegir origen, destino y bases.
  • dbclone -from staging -only mongo:shop,mysql:app -yes: la versión no interactiva, de staging a local.

El autor menciona PostgreSQL como el próximo motor (hay un paquete por motor en internal/driver/<engine>/). Si algo se rompe en tu setup, pide un issue con la carpeta logs/ de esa corrida.

Si tu staging vive en un VPS o en un servidor cloud (en donweb.com, por ejemplo), la condición práctica es la de siempre: el puerto de la base tiene que ser alcanzable desde los contenedores de tu laptop, con un usuario de solo lectura para el origen.

Qué está confirmado y qué no

Lo confirmado sale del post y del README del propio autor. Lo que falta son pruebas de terceros y nuestras.

  • Confirmado por la fuente: el funcionamiento por docker exec, los pipes sin archivo, el umbral de 64 MiB, los valores por defecto -j 8 y -w 4, los 3 reintentos y la advertencia de consistencia en MySQL.
  • No verificado: rendimiento en tu red, comportamiento con bases de decenas de GB y las garantías de seguridad. Nosotros no corrimos pruebas ni mediciones.
  • Criterio de verificación (propuesta editorial, no del autor): después de la primera corrida contra una base chica, compará conteos de filas por tabla y de documentos por colección entre origen y destino, y revisá la carpeta logs/. Como cada grupo de tablas tiene su propio snapshot, esperá diferencias entre tablas relacionadas si el origen recibe escrituras durante la copia.

Errores comunes

  • Usarlo como backup. La copia no es consistente entre tablas. Corrección: para respaldos usá una herramienta pensada para eso.
  • Contenedores con otro nombre. Por defecto dbclone busca mongodb y mysql. Si los tuyos se llaman distinto, definí DBCLONE_MONGO_CONTAINER o DBCLONE_MYSQL_CONTAINER.
  • Contenedores sin credenciales root en el entorno. Necesitan MONGO_INITDB_ROOT_USERNAME y MONGO_INITDB_ROOT_PASSWORD para Mongo, y MYSQL_ROOT_PASSWORD para MySQL.
  • Servidor alcanzable desde la laptop pero no desde el contenedor. El README pide que el remoto se alcance desde adentro de los contenedores.
  • Permisos cortos en MySQL. El usuario de origen necesita SELECT, SHOW VIEW y TRIGGER. Sin EVENT, los eventos se saltean con una advertencia.
  • Clonar solo algunas tablas y esperar rutinas. Si copiás un subconjunto de una base MySQL, las rutinas y los eventos no se copian.

Preguntas Frecuentes

¿Cómo clonar una base de datos de staging a mi laptop?

Con dbclone, corriendo dbclone -from staging -only mongo:shop,mysql:app -yes después de crear el perfil de staging. Necesitás Docker con contenedores locales de las imágenes oficiales mongo y mysql. El destino por defecto es local. Lo complementamos en seguridad de la base de datos en WordPress.

¿Cómo usar mongodump y mysqldump desde un contenedor Docker?

Las imágenes oficiales ya traen esas herramientas, y dbclone las ejecuta con docker exec en el contenedor local. Cada dump se conecta por pipe a su restore, y el cliente tiene la misma versión mayor que el servidor que restaura. Ya lo cubrimos antes en versionar el esquema con Liquibase y Spring Boot.

¿Se puede restaurar un dump de MongoDB sin instalar el cliente en el host?

Sí, si tenés un contenedor mongo oficial: trae mongorestore y dbclone lo usa desde adentro. No hace falta instalar nada en tu sistema.

¿Qué hace mysqldump –single-transaction y es consistente entre tablas?

Toma un snapshot consistente de lo que vuelca cada proceso, pero en dbclone cada grupo de tablas corre su propio mysqldump, así que cada grupo tiene su propio snapshot. El resultado no es un punto en el tiempo único entre tablas, según el autor.

¿Qué es dbclone y cómo se instala?

dbclone es una CLI en Go con licencia MIT que clona bases de MongoDB y MySQL entre perfiles. Se instala con go install github.com/phuthuycoding/dbclone@latest, con Homebrew, con Scoop o con un binario de GitHub Releases.

Conclusión

dbclone cambia un procedimiento de wiki por un comando, y lo hace con una idea simple: usar las herramientas que ya están dentro de tus contenedores. Eso elimina el problema de versiones y el archivo de dump intermedio. Lo que no cambia es su alcance: es para datos de desarrollo, y es un proyecto de un solo autor sin auditoría independiente.

Mi recomendación: corré dbclone -check, probalo con una base chica de staging, comparalo con los conteos de origen y recién después pensá en bases grandes. Si tu staging tiene datos personales, anonimizalos antes de que lleguen a una laptop.

Fuentes

Te puede interesar...