Tener copias de seguridad: Backup and Migrate

 Aquí, una semana más en Drupalizate, este podcast donde yo, a Robert Menetray, te cuento cosillas a tener en cuenta cuando desarrollas webs en Drupal. Esta semana me he apuntado que quiero hablar sobre el tema de los backups. Así que primero de todo, ¿qué es un backup? Pues una copia seguridad, creo que hasta aquí la mayoría de gente llega. Cosas a tener en cuenta para los backups. En Drupal tenemos que hacer tres tipos de backup distintos. El primero es la base de datos, por supuesto, porque tenemos gran parte de los contenidos de la web están en base de datos, en un MySQL normalmente. Después tenemos un backup de lo que es el código. Aunque la mayoría del código está en Git, que se puede considerar una especie de backup, hay partes que no están en Git, como puede ser por ejemplo algún settings o algún fichero que está excluido del Git. Así que podría ser bien tener un backup de lo que es la parte del código como tal. Y después también la parte que hay gente que se olvida, que es el de los ficheros. El Sites Default Files, que es lo que viene por defecto, a menos que lo hayas cambiado. Básicamente son las imágenes o documentos PDF o cualquier tipo de documento que haya subido a la web. Cualquier cosa que sea contenido, que no esté en la base de datos, estará aquí. Como digo, casi siempre son PDFs y imágenes. Hay casos que se ponen más cosas, hay fichos de audio o de video, pero no es lo normal. El problema es que he visto gente que solo tiene backups de base de datos. No tiene backups ni de código, y hay gente que ni siquiera usa Git. Y también hay gente que ni siquiera tiene backups de sus imágenes. Con lo cual, si es un portal que tienes productos o que tienes contenido con muchas imágenes, pues pueden ser gigas de datos o imágenes que no están teniendo backups. Si pasa algo, si te hackean, si el servidor se quema, si pasa lo que sea, deberías tener un backup para poder restaurar tanto la base de datos, tanto las imágenes, o sea, los ficheros, y por supuesto el código para que la web siga funcionando. Y también hay una cuarta cosa que sería lo que es la configuración del servidor como data. Si en general se ha configurado un PHP de determinada forma, se usa Memcache o Redis, o se usa Elastic o Solar, o se usa Apache o NGINX, tener una copia de cómo está el servidor para poder restaurar completamente y rápidamente una copia entera de todo podría ser recomendable. Vale, dicho todo esto, ¿qué opciones tenemos dependiendo de qué tipo de hosting tengamos en la web? El hosting es donde se aloja la web. Digamos que de forma muy básica tenemos lo que es hosting compartido, que yo no recomiendo para nada. Si es una web muy simple puede tener sentido, pero por el precio que tiene un hosting dedicado o un VPS, yo realmente tiraría por un VPS. El compartido, no sé, a mí no me gusta. También por el tipo de proyectos a los que estoy acostumbrado, un compartido da más problemas que otra cosa. Los hostings compartidos normalmente te hacen una copia de lo que es código y ficheros, todo junto, y una copia de la base de datos que ahora parte. Por ejemplo, cuando tenemos un Z-panel o estas cosas. Después tenemos lo que es un VPS, que en algunos casos te lo tienes que configurar todo tú, y en otros casos la empresa que has contratado te lo gestiona todo ellos. Hay empresas que lo que hacen es copia de lo que es ficheros y código, todo junto. Básicamente es todo lo que está debajo de este directorio, que es donde está la web, pues se hace un zip con todo. Y después lo que está en base de datos se exporta a la base de datos y se añade dentro de este zip. Después hay otras empresas que lo que hacen es, no, no, lo tenemos por separado. Una cosa es lo que tenemos en código, otra cosa es lo que tenemos en este directorio, que son los ficheros estáticos, como son imágenes o PDFs, y otra cosa distinta es lo que tenemos en la base de datos. Lo que nos permite seleccionar qué tipo de backup queremos recuperar en el momento que pase algo. O sea, hay no que hemos eliminado una página, pues quizá solo recuperando el backup de base de datos tenemos suficiente. O hay no que no se quede las imágenes o PDFs, pues quizá recuperando solo el backup de imágenes o ficheros ya tenemos bastante. Otro tema de los backups importante, aparte de que si pasase algo en producción, poder restablecer esa copia, es el duplicar ese entorno y tener una copia para desarrollo o para preproducción. O sea, al final esto que te da la web, una copia que no esté en producción, que si peta algo, que si la lias, que si rompes algo, no rompas la web que está en producción. Con lo cual cuando tienes estos backups por separado de ficheros, base de datos y código, puedes especificar que hay una copia de lo que tenemos ahora mismo en código en producción, pero con lo que tenemos actualmente de ficheros. No lo que está en producción, sino lo que teníamos en preproducción de ficheros. O sea, podemos jugar con los tres tipos de backup y no hacer un backup, o sea, no restablecer un backup de los tres al mismo tiempo. No sé si me he explicado, creo que sí. La forma que tenemos en algunos servidores, normalmente los compartidos, puede ser de que o no tengamos backup o que tengamos es una porquería. Puede tener sentido usar módulos, que básicamente tenemos uno, el más importante en Drupal, que es backup and migrate, que justamente hace que la propia web se pueda autogenerar sus propios backups. Lo recomiendo en determinados casos muy concretos. A ver, básicamente no lo recomiendo para webs que son muy grandes, que tengan muchas imágenes o muchos documentos, o que tengan una base de datos muy grande, con muchos contenidos. Si son webs pequeñitas o medianas, puede tener sentido tenerlo. Puede tener sentido tenerlo aunque tu servidor te gestione también los backups, depende de cómo seas de paranoico. O sea, que tu web te genere un backup y al mismo tiempo el servidor te genere otro backup, pues tienes dos backups, que si pasase algo, pues tienes una doble copia de seguridad. Si llega a pasar algo, tienes menos posibilidades de que uno de los backups esté corrupto. Así que puede tener sentido tener dos backups generados de forma distinta. El modo backup and migrate, básicamente es un modo que lo instalas, tiene una configuración digamos bastante minimal, aunque lo puedes extender y por ejemplo, podría, a ver, esto no lo he explicado, backup and migrate por defecto te genera un zip, o un fichero con todo y te lo guarda en una ruta en tu propio servidor. El problema con esto es que tiene que ser una ruta donde el propio Drupal pueda escribir. En muchos casos, en muchos servidores, esto significa que la propia ruta donde Drupal puede escribir es una ruta accesible desde internet. Vale, con lo cual, si es una copia de seguridad con todo el contenido de la web, si alguna persona se la puede descargar, básicamente es un riesgo de seguridad alto de privacidad de datos, pues cualquier persona que se baje esa copia de seguridad puede montar tu web y ver todos los datos que tiene dentro. Así que cuidado cuando pones este módulo, revisa correctamente que las copias que se generan no sean descargables, o sea que el directorio no sea visible a internet. Esto sobre todo lo digo cuando tienes un servidor que usa engines, que no usa lo que es el htaccess, porque Drupal por defecto bloquea el acceso a los directorios con htaccess, porque claro, si tienes un engine ese bloqueo no es, con lo cual, este es permitiendo que cualquier persona pueda navegar por los directorios, encontrar backups y bajárselos. Así que cuidado. Me ha dicho esto, el problema que tenemos aquí es que estamos guardando ficheros grandes, o sea, unas copias te pueden ocupar varios gigas, si estamos sumando lo que son imágenes PDFs y un backup de la base de datos que puede ser de megas o de gigas, y claro, si tenemos una copia cada día y guardamos dos semanas de copias, ya no digo un mes, digo una semana o dos, depende de la capacidad en disco de tu servidor, pues puedes tener problemas de espacio. El backup de migray te permite que los backups se muevan a un servidor externo. Básicamente, mírate en un detalle si te interesas esto, pero hay sub módulos que te permiten conectar con servicios externos, como por ejemplo, Dropbox o Amazon o directamente por FTP, me suena que había uno, y mueven el fichero ya generado a una ubicación externa, con lo cual te ahorras el tema de que te falte espacio en disco. O sea, te hace falta tener un disco decente, pero no uno hiper grande para guardar todas las copias ahí dentro. Esto también tiene la ventaja de que si llegase a pasar algo y el servidor, por ejemplo, se quema, se quema el data center, el edificio donde están tus servidores, eso le pasó el año pasado a los de OVH, que es una empresa francesa, si tienes los backups dentro de tu propio servidor y el servidor se elimina, se quema o lo que le pase, claro, has perdido tu web y los backups que estaban dentro de tu mismo servidor, así que es buena idea tener los backups en un servidor externo, al menos una copia cada cierto tiempo. Y poca cosa más, si básicamente no tienes copias de seguridad, debías tenerlas, una forma fácil es usando este módulo. Si tienes mucho contenido, puede ser que este módulo te de problemas por tiempos de ejecución y que puede llegar a generar backups corruptos o que no llegue a generar backup. Si por tiempo de ejecución la configuración de PHP te corta la generación de este backup. De vez en cuando revisa que los backups, o sea, realmente cuando generas un backup, ya sea que lo gestione el servidor o lo creas tú con este módulo, de vez en cuando estaría bien probar que el backup realmente funciona y que no salen todos corrompidos, que también lo he visto. De webs crece pensando, sí, sí tengo un backup y después del backup es inusable. De vez en cuando prueba que el backup se puede usar y te ahorra ya sustos si realmente llegas a tener una emergencia y te hace falta tirar de los backups. Y otra cosa a tener en cuenta con el tema de backups, sobre todo de la base de datos. Depende de cómo se genere y en el caso del backup Amigate, sí, se genera así. Hacemos una consulta, digamos, bestia, la base de datos, con lo cual estás bloqueando la base de datos y si tienes una base de datos, digamos, muy grande, estás bloqueando la base de datos durante cierto tiempo. Si tienes muchas visitas al mismo momento, puede ser que tengas la web caída unos momentos. Esto puede ser factible si haces el backup en determinadas horas donde no tienes nadie que visite tu web, por ejemplo, la una de la mañana, pero puede ser que tu proyecto tenga que estar levantado 24 horas, no puede ser que esté caído ni un minuto. En este caso quizá no es la mejor opción. Quizá es la mejor opción que esto se gestione a nivel del servidor y que evites que la web se caiga en ningún momento. Esto mejor háblalo con alguien de sistemas, alguien que te gestione el servidor o el hosting y que te dé la mejor opción él, ¿vale? Al final el backup Amigate es para una solución alternativa, gratuita y fácil de implementar, pero no debería ser tu primera opción para el tema de backups, ¿vale? Y nada más, que creo que me ha dado demasiada cuenta para este mini episodio de hoy. Hasta semana que viene. ¡Chau!