Simple, automated and low cost MySQL backup strategy

Setting up a mysql backup strategy it’s hardly an exciting task, so having a simple solution it’s key to actually get it out of your to-do list.

Here’s a simple, automated and low-cost alternative that I use to keep MySQL database backups of small to medium-sized projects.

Setting up automatic backups

automysqlbackup it’s a simple shell script that automates the creation of daily, weekly and monthly MySQL backup.

It’s available on the repositories for Debian and Ubuntu. The project it’s officially hosted on SourceForge but you can also find lots of several of forks hosted on GitHub.

If you’re using Ubuntu, the installation it’s completely straightforward; all you need it’s sudo apt install automysqlbackup and you’re done.

Backups are saved on /var/lib/automysqlbackup, organized by daily/weekly/monthly directories and then by database name.

There are a few settings that you can modify on /etc/default/automysqlbackup, such as the backup dir, whether to send informative e-mails or to keep a “latest” directory.

Off-site backups

Of course, having automated backups it’s just part of the solution: you need to keep an off-site copy of your data in case your server it’s compromised.

A very simple and cheap alternative it’s using Google Drive as external storage: for USD 1.99 you get 100 GB which are shared with other Google services such as Photos and Gmail, but even the free 15 GB are plenty.

For saving your backups to Drive you can use drive, which it’s a tiny program to pull or push files to the service. There are several platform packages for various distributions.

After the installation, you need to initialize the client, so you can get an OAuth token to authorize the application access to your Drive account.

The client doesn’t do synchronization, it trusts the user to determine the authoritative version of a file or folder, which might be problematic in some cases but it’s specially useful for copying the backups, since that will automatically take care of deleting older backups —which you can still find on your “Trash” for 30 days since deletion.

You can set a daily cron job to upload your latest backups using something like this:

25 4 * * * cd /root/gdrive/mysql-backups && drive push -no-prompt

The Cultural Defeat of Microsoft

Many people (by which I mean many Windows users”) don’t realize the huge difference between “the Windows way of doing things” and, basically, everyone elses’ way, i.e: the POSIX world which comprises all of the Unices, Linux, BSD and even OS X.

Hugo Landau writes:

From the perspective of POSIX, Windows is “alien technology” […] Windows and POSIX are fundamentally different in many ways, and lead to further “cultural” differences in how software is developed on these platforms. Windows and POSIX, then, are two “cultures”, the technical differences of the core technology itself being only a small part of that.

Read the entire piece at: The Cultural Defeat of Microsoft

Using Envoy to automate repetitive tasks

Envoy is a task runner originally developed for Laravel, but that you can also use on any other kind of project.

It’s a very easy way to define tasks with Blade syntax and simple terminal commands, which you can run on remote servers via SSH (including parallel execution) or locally.

Thanks to its simplicity, it’s great to quickly automate repetitive tasks. For instance, this is something I use for importing a replica of the production DB of a site:

@servers(['production' => 'foobar.com', 'local' => 'localhost'])

@macro('sync-db')
    dump-production-db
    get-production-db
    import-production-db
@endmacro

@task('dump-production-db', ['on' => 'production'])
    echo 'Creating production DB dump';
    cd ddbb
    mysqldump --no-autocommit --skip-extended-insert --single-transaction --ignore-table=foobar.wp_simple_history_contexts --ignore-table=foobar.wp_simple_history_history foobar_production | gzip > foobar.production.sql.gz
@endtask

@task('get-production-db', ['on' => 'local'])
    echo 'Copying DB dump from production server';
    cd ddbb
    rsync -P foobar:~/ddbb/foobar.production.sql.gz .
@endtask

@task('import-production-db', ['on' => 'local', 'confirm' => true])
    cd ddbb
    gzip -d -f foobar.production.sql.gz
    sed 's/www.foobar.com/www.foobar.lo/g' -i foobar.production.sql
    echo 'Importing production DB replica';
    mysql -v foobar_development < foobar.production.sql
@endtask

Importar tu base de datos de WordPress (de la forma más rápida)

Uno de los grandes aprendizajes que he podido aplicar al desarrollo de sitios con WordPress, y del cual soy particularmente entusiasta de sermonear es la necesidad de mantener una versión local de desarrollo lo más parecida posible a lo que vas a utilizar en producción, lo que además se apoya y soporta un montón de otras buenas prácticas como evitar el cowboy coding, utilizar control de versiones, etc.

Puesto que para el cliente no se trata de uno de los objetivos del proyecto, la capacidad de importar una base de datos para tener una réplica de desarrollo debe ser algo sencillo y rápido de ejecutar. Aunque existen múltiples plugins y herramientas para hacerlo, para mí la forma más sencilla es recurrir a herramientas muy básicas a través de la línea de comandos.

Continue reading “Importar tu base de datos de WordPress (de la forma más rápida)”

HOWTO: Install Node+NPM as user (not root)

HOWTO: Install Node+NPM as user (not root) – if you need to use node.js/npm/grunt/bower and using a shared hosting or can’t/won’t/don’t want to install as root… here’s how you can still get away with it. You’re still going to need something like build-essential installed, though

Actualizaciones de seguridad automáticas en Ubuntu

Un tip breve pero muy útil, casi necesario: si estás a cargo de algún servidor, puedes activar la instalación automática de actualizaciones de seguridad lo que alivia bastante la carga ante anuncios de vulnerabilidades.

Para Ubuntu, puedes consultar la siguiente guía en su documentación comunitaria: Automatic Security Updates.

Las actualizaciones de seguridad se distribuyen a través de un repositorio específico, y cuando se publica una nueva versión por lo general va a estar limitada a solucionar una vulnerabilidad, por lo que el riesgo de que surja alguna incompatibilidad es muy baja.

Cómo asegurar las cookies de acceso a tu sitio WordPress

Recientemente se ha dado a conocer una vulnerabilidad en el sistema de autenticación de usuarios para los sitios con WordPress, que básicamente consiste en lo siguiente:

  • La vulnerabilidad afecta tanto a sitios en WordPress.com como instalaciones propias.
  • Al acceder a la administración de tu sitio, WordPress crea una cookie que le permite validarte como un usuario que ha iniciado sesión.
  • Una gran cantidad de sitios con WordPress no funciona sobre HTTPS, por lo que la cookie se envía como texto plano.
  • Un atacante puede interceptar esa cookie, insertarla en su navegador, y luego hacerse pasar por el usuario que ha iniciado sesión. Esto es particularmente fácil en situaciones donde hay transmisiones “abiertas” de datos, por ejemplo en un café donde la conexión no tiene contraseña.
  • La cookie sigue siendo válida aun cuando el usuario cierre su sesión, por lo que podrías ingresar a tu administrador, cerrar la sesión, y el atacante aun tendría acceso.
  • El tiempo de expiración de la cookie es de 3 años en blogs de WordPress.com y 14 días en instalaciones propias.

Ahora pasemos a lo importante, ¿cómo evitarlo?

En primer lugar, la opción más sencilla pero seguramente inefectiva es la abstinencia: simplemente, evitar acceder a la administración de WordPress en redes no confiables. Pero como estamos hablando de seguridad, y en este sentido no se puede ser demasiado paranoico, desechemos esta opción.

Continue reading “Cómo asegurar las cookies de acceso a tu sitio WordPress”