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.