Backups de WordPress en Linode Object Storage

By | March 22, 2020
0 Comment

En Linode tengo además del servicio de backup de servidores que me permite recuperar una máquina entera, una serie de backups locales de WordPress -tanto de contenido como de Base de Datos- que me permite restaurar mis sitios web a un punto específico sin tener que recuperar todo el servidor.

Estos backups de WordPress son candidatos para subirlos a un bucket de Linode Object Storage:

  • No son demasiado grandes: actualmente la limitación de objeto en Linode es de 5 GB y mis backups de WordPress llegan apenas a 2GB.
  • Contenido estático: una vez realizado el backup éste no cambia, sólo lo necesitaré en caso de tener que recuperar algo.
  • Más económico: contratar 250GB de Object Storage son 5€ frente a los 25€ por 250GB de Block Storage para seguir almacenando en local.

No obstante, conviene que echéis un vistazo a las limitaciones y precios para haceros una idea y ver si se adapta a vuestras necesidades si os decidís a utilizarlo.

Instalación y configuración de s3cmd

Hay varias herramientas para trabajar con Object Storage. Yo utilizo la herramienta s3cmd de Amazon que permite gestionar almacenamiento S3 compatible como el de Linode además de otros proveedores de hosting.

Para instalarla según distro:

# Debian & derivadas
apt-get install s3cmd

# RHEL & derivadas
yum install s3cmd

Una vez contratado Object Storage en Linode, tendremos que crear un par de claves (Access y Secret) que necesitaremos para configurar el cliente s3cmd. Lanzamos la configuración con:

s3cmd --configure

Seguimos los distintos pasos de configuración:

Enter new values or accept defaults in brackets with Enter.
Refer to user manual for detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3. Leave them empty for using the env variables.
Access Key: miaccesskey
Secret Key: misecretkey
Default Region [US]: 

Use "s3.amazonaws.com" for S3 Endpoint and not modify it to the target Amazon S3.
S3 Endpoint [s3.amazonaws.com]: us-east-1.linodeobjects.com

Use "%(bucket)s.s3.amazonaws.com" to the target Amazon S3. "%(bucket)s" and "%(location)s" vars can be used
if the target S3 system supports dns based buckets.
DNS-style bucket+hostname:port template for accessing a bucket [%(bucket)s.s3.amazonaws.com]: us-east-1.linodeobjects.com

Encryption password is used to protect your files from reading
by unauthorized persons while in transfer to S3
Encryption password: MIPASSGPG
Path to GPG program [/usr/bin/gpg]: 

When using secure HTTPS protocol all communication with Amazon S3
servers is protected from 3rd party eavesdropping. This method is
slower than plain HTTP, and can only be proxied with Python 2.7 or newer
Use HTTPS protocol [Yes]: Yes

On some networks all internet access must go through a HTTP proxy.
Try setting it here if you can't connect to S3 directly
HTTP Proxy server name: 

New settings:
  Access Key: MIACCESSKEY
  Secret Key: MISECRETKEY
  Default Region: US
  S3 Endpoint: us-east-1.linodeobjects.com
  DNS-style bucket+hostname:port template for accessing a bucket: us-east-1.linodeobjects.com
  Encryption password: ENCRYPTIONPASSWORD
  Path to GPG program: /usr/bin/gpg
  Use HTTPS protocol: True
  HTTP Proxy server name: 
  HTTP Proxy server port: 0

Test access with supplied credentials? [Y/n] y
Please wait, attempting to list all buckets...
Success. Your access key and secret key worked fine :-)

Now verifying that encryption works...
Success. Encryption and decryption worked fine :-)

Save settings? [y/N] y
Configuration saved to '/home/jota/.s3cfg'

Crear un bucket y operar con objetos

Una vez configurado el cliente, creo un bucket llamado jota-backups-bucket donde iré almacenando mis backups como objetos:

[jota@jotadev ~]$ s3cmd mb s3://jota-backups-bucket
Bucket 's3://jota-backups-bucket/' created

Reviso en Linode que se ha creado el bucket:

Subo mi backup al bucket jota-backups-bucket:

[jota@jotadev ~]$ s3cmd put wp_backup_20200226.tar.gz s3://jota-backups-bucket
upload: 'wp_backup_20200226.tar.gz' -> 's3://jota-backups-bucket/wp_backup_20200226.tar.gz'  [1 of 1]

De nuevo en mi cuenta de Linode compruebo que se ha subido el objeto:

Si quisiera recuperar el backup:

[jota@jotadev ~]$ s3cmd get s3://jota-backups-bucket/wp_backup_20200226.tar.gz
download: 's3://jota-backups-bucket/wp_backup_20200226.tar.gz' -> './wp_backup_20200226.tar.gz'  [1 of 1]

Para borrar el objeto del bucket:

s3cmd rm s3://jota-backups-bucket/wp_backup_20200226.tar.gz

Para borrar todos los objetos del bucket:

s3cmd del --recursive s3://jota-backups-bucket

Y finalmente para eliminar el bucket (tiene que estar vacío):

s3cmd rb s3://jota-backups-bucket

Ciclo de vida: eliminando objetos antiguos

Mis backups son semanales y me interesa mantener los últimos 4 backups, siempre un mes. Para ello creo una política de ciclo de vida en el fichero jota-backups-lifecycle-policy.xml con el siguiente contenido:

<LifecycleConfiguration>
    <Rule>
        <ID>delete-all-objects</ID>
        <Prefix></Prefix>
        <Status>Enabled</Status>
        <Expiration>
            <Days>30</Days>
        </Expiration>
    </Rule>
</LifecycleConfiguration>

Subo la política al bucket donde quiero aplicarla:

[jota@jotadev ~]$ s3cmd setlifecycle jota-backups-lifecycle-policy.xml s3://jota-backups-bucket
s3://jota-backups-bucket/: Lifecycle Policy updated

Compruebo que está aplicada:

[jota@jotadev ~]$ s3cmd getlifecycle s3://jota-backups-bucket
<?xml version="1.0" ?>
<LifecycleConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
	<Rule>
		<ID>delete-all-objects</ID>
		<Prefix/>
		<Status>Enabled</Status>
		<Expiration>
			<Days>30</Days>
		</Expiration>
	</Rule>
</LifecycleConfiguration>

Y para eliminarla:

s3cmd dellifecycle s3://jota-backups-bucket

Para más información podéis consultar la extensa documentación de Object Storage en Linode.