Como planear una buena estrategia de Back Up

En el día de hoy uno de mis clientes me pidió, casi rogándome, que le devuelva al estado original uno de sus sitios que tiene alojados en uno de mis servidores. Pedido al cual accedí sin hacer ningún comentario ya que es algo normal que por un error involuntario del cliente, los archivos se pierden o algo por el estilo.

La sorpresa me la llevé al preguntarle la fecha de la cual quería recuperar la copia. El cliente me contestó que la quería recuperar desde el primer día que había puesto online el sitio, hacía más de 3 años.


Sorprendido por el tiempo que pedía, le explique que eso era imposible ya que el tiempo de retención máximo de una copia de seguridad en estos servidores, era de 1 mes y a pedido del cliente 1 año, pero jamás haciamos copias con semejante tiempo de retención.

Finalmente, y luego de explicarle lo siguiente, el cliente entendió que la política era correcta.

Una buena estrategia o política de backup se realiza dividiendo en dos partes. La parte lógica, es decir la del código o programa para realizar el backup, y la parte física, es decir el almacenamiento de las cintas, discos u otros medios donde se realice la copia.



Vamos a empezar por la parte física.

La lógica dice que si uno quiere mantener algo seguro, debe alejarlo del peligro o de donde pueda llegar a existir alguna clase de riesgo.

En mi caso, las copias de seguridad se almacenan en un edificio apartado al del edificio donde se encuentran los servidores. Porque esto? Es muy simple… Si estoy almacenando una copia de seguridad en un lugar donde si se puede prender fuego, inundar etc., lo lógico sería que no afecte a los dos puntos de información. El servidor y la cinta de backup.

¿Que otras hipótesis tenemos que tener en cuenta para no sufrir la perdida de la informacion? Básicamente no guardar la copia de seguridad en el mismo disco, realizar los backups de forma periódica y comprobar cada x cantidad de días que la copia se haya realizado correctamente.

¿Que pasa si los dos lugares sufren desperfectos que imposibiliten recuperar la información tanto de la cinta como del servidor? La pregunta que nos hacemos es… ¿Puede llegar a pasar? Si, ¿pero con que probabilidad? no importa la probabilidad en este caso, ya que uno no puede estar jugando con la suerte si los datos que se guardan son datos críticos. Para este tipo de situaciones, se realizan las copias de seguridad en diferentes ubicaciones muy alejadas una de otra. De más está decir que los lugares donde se guarden las cintas como así también los que contengan los servidores, deben estar acondicionados para tal función, con fuentes de energía redundante, doble acceso a Internet y sistemas de control de ingreso entre otras cosas.



Ahora tomamos la parte lógica

Es decir, el código o programa para realizar el backup.

Existen muchisimos programas para realizar copias de seguridad en un servidor. Desde pagos hasta gratuitos, pero sin desmerecer a ninguno, yo opto por realizar el mismo a través de la linea de código, utilizando el comando “cron” en unix. Con este comando, uno puede definir el momento exacto en el que se ejecutará un backup u otra accion planificada.

Para la estrategia de backup, se definió lo siguiente:

- Cada hora se realiza un dump de las bases de datos de los clientes y se envían a las dos ubicaciones donde se almacenan en cinta.

- Diariamente, a las 2 AM, se ejecuta el comando que copia los archivos de unos directorios específicos de cada cliente, y se envían a las dos ubicaciones de backup disponibles.

- Semanalmente, los archivos que se encuentren con fecha de modificación superior a una semana, se copian y se envían a las dos ubicaciones de backup.

- Mensualmente se realiza lo mismo que en el punto anterior, pero con fecha de modificación superior al més.



Todos los meses, se realiza un chequeo de rutina para revisar si los backups se realizaron correctamente. Las cintas con fecha superior al mes, si el cliente no pidió mayor retención, se reutilizan. En caso contrario, se separan hasta que se cumpla el año.

Esta estrategia es muy simple, pero llevo tiempo pulirla. La pongo a disposición de ustedes para que la analicen, la modifiquen y comenten lo que crean necesario.

 

Esto depende de el numero de cuentas por servidor puede ser viable o no, ya que estar realizando continuamente dumps del mysql puede penalizar bastante la velocidad de carga de las paginas web, sobre todo el first byte, y en horas puntas de mas trafico puede relentizarte mucho el servidor, lo recomentable que los dumps completos los realices por la noche. Si es un mandatorio sacar volcados cada hora del mysql deberias plantearte montar un mysql replicado y sacar los dumps directamente de el para no penalizar la carga del servidor donde consultan las paginas web.

Realiza las copias incrementales, para no generar trafico inecesario y hacerlas mas rapido


He visto que en la firma que empleas estais usando cpanel en el servidor de beeono, La gestion que comentas vas a usar el backup interno del cpanel o una solucion de terceros?

 

Estas tomando un post de hace un mes, esto fue pulido y mejorado en este tiempo.

Nuestros mysql estàn replicados, y los bkps se toman en el de contingencia.

Por supuesto que las copias son incrementales, realizar copias de archivos no modificados, a parte de ser una pérdida de tiempo, es costoso en cuanto a espacio en cinta.

Finalmente, usamos una solución desarrollada por nuestro equipo para tomar backups ya que se adapta más a nuestras necesidades de escalabilidad.

 

Insólito lo que hay que escuchar, lo que no entiendo que como va pedir backup de dos años si tu dominio lleva un año recién, y poco tiempo en funcionamiento(vendiendo servicios)

:O

 

muy facil porque hace 2 años ya era su cliente, le pudo hacer un programa, una web, venderle hardware y desde hace un año amplio y ahora tambien se dedica al hosting comercial y fuera de su ciudad

 

Es sorprendente que una persona que recien ingresa al foro, difame de esta manera...

El dominio beeone.com.ar se encuentra registrado desde el 12/11/2009.
Ese era nuestro dominio principal. Cuando empezamos a abrirnos a otros mercados como consultoría SAP, desarrollo de aplicaciones etc, tomamos como principal beeonesolutions.com y beeonesolutions.com.ar

Tan simple como esto...