<?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/en/tags/restore/</link><description>Recent content in Restore on Ivan Luminaria</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 14 Apr 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/en/tags/restore/index.xml" rel="self" type="application/rss+xml"/><item><title>mysqldump vs mysqlpump vs mydumper: the backup that keeps you up at night</title><link>https://ivanluminaria.com/en/posts/mysql/mysqldump-mysqlpump-mydumper/</link><pubDate>Tue, 14 Apr 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/en/posts/mysql/mysqldump-mysqlpump-mydumper/</guid><description>&lt;p&gt;The call came on a Friday afternoon — because these things always happen on Fridays. The DBA from a logistics client messages me on Teams: &amp;ldquo;Last night&amp;rsquo;s backup took three and a half hours. This morning users found the application sluggish at 8 AM. Can we talk?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;We could talk. In fact, we should have talked about this a while ago.&lt;/p&gt;
&lt;p&gt;The setup was a classic: MySQL 8.0 on Rocky Linux, roughly 60 GB database, a business application with about thirty InnoDB tables, four or five of which were truly large — the orders table, the warehouse movements table, the tracking history. The backup ran every night via a mysqldump launched by cron at 2:00 AM. It had worked for years. The problem was that the database had grown in the meantime.&lt;/p&gt;</description></item></channel></rss>