<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Restore on Ivan Luminaria</title><link>https://ivanluminaria.com/es/tags/restore/</link><description>Recent content in Restore on Ivan Luminaria</description><generator>Hugo</generator><language>es</language><lastBuildDate>Tue, 14 Apr 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/es/tags/restore/index.xml" rel="self" type="application/rss+xml"/><item><title>mysqldump vs mysqlpump vs mydumper: el backup que no te deja dormir</title><link>https://ivanluminaria.com/es/posts/mysql/mysqldump-mysqlpump-mydumper/</link><pubDate>Tue, 14 Apr 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/mysql/mysqldump-mysqlpump-mydumper/</guid><description>&lt;p&gt;La llamada llegó un viernes por la tarde — porque estas cosas siempre pasan en viernes. El DBA de un cliente del sector logístico me escribe por Teams: &amp;ldquo;El backup de anoche tardó tres horas y media. Esta mañana los usuarios encontraron la aplicación lenta a las 8. ¿Podemos hablarlo?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Podíamos hablarlo, sí. De hecho, deberíamos haberlo hablado hace tiempo.&lt;/p&gt;
&lt;p&gt;El setup era un clásico: MySQL 8.0 sobre Rocky Linux, base de datos de unos 60 GB, un gestional con unas treinta tablas InnoDB de las cuales cuatro o cinco eran realmente grandes — la tabla de pedidos, la de movimientos de almacén, la historización de tracking. El backup se hacía cada noche con un mysqldump lanzado por cron a las 2:00. Había funcionado durante años. El problema es que la base de datos mientras tanto había crecido.&lt;/p&gt;</description></item></channel></rss>