Backup automatico di un database MariaDB

<h2>Backup non replica</h2><p>La replica protegge dai guasti hardware ma non da errori umani, corruption silenziosa o ransomware. Servono backup veri su storage separato con retention adeguata per tutti i casi di emergenza.</p><h2>mysqldump corretto</h2><p>Usa sempre --single-transaction per InnoDB: crea un punto di consistenza senza bloccare le tabelle. Aggiungi --routines e --triggers per includere stored procedure. Comprimi il dump con gzip in pipe per risparmiare spazio.</p><h2>Credenziali sicure</h2><p>Non mettere mai la password nella linea di comando: appare in ps e nella bash history. Usa un file ~/.my.cnf con sezione client contenente user, password e host. Imposta permessi 600 su questo file.</p><h2>Script di backup robusto</h2><p>Uno script robusto include: creazione directory di destinazione, dump con timestamp nel nome, verifica che il file non sia vuoto, pulizia dei backup piu vecchi del retention period e notifica in caso di errore.</p><h2>Schedulazione e monitoraggio</h2><p>Schedula il backup con cron alle 3 di notte. Usa healthchecks.io o uptime-kuma come dead-man's switch: il job segnala il completamento e se non arriva il segnale ricevi un alert immediato via email o Matrix.</p><h2>Test di restore</h2><p>Un backup non testato non esiste. Ogni 3 mesi esegui un restore di test in database temporaneo e verifica i conteggi delle tabelle critiche. Solo dopo puoi considerare il backup realmente affidabile.</p><h2>Conclusione</h2><p>Backup database affidabili sono la differenza tra un'interruzione di 2 ore e una perdita catastrofica. Investire un giorno in setup robusto con test di restore e il miglior investimento possibile.</p>

📄 Info pagina