Una aplicaci\u00f3n SQL Server en funcionamiento en realidad es una colecci\u00f3n de bases de datos. Adem\u00e1s de los datos en s\u00ed, incluye bases de datos del sistema y el registro de transacciones. Para poder restaurar la aplicaci\u00f3n sin tropiezos, todo esto tiene que estar protegido. A continuaci\u00f3n encontrar\u00e1 algunos consejos y buenas pr\u00e1cticas de Restauraci\u00f3n y backup con SQL Server.<\/p>\n\n\n\n
A diferencia de muchos programas, SQL Server permite la realizaci\u00f3n de backups mientras los usuarios est\u00e1n activos y se est\u00e1n procesando transacciones. Esto significa que se puede hacer backup mientras se est\u00e1 utilizando el sistema. Pero como el backup de SQL Server ocupa recursos, en especial E\/S, es mejor realizar backups completos en momentos en los que el sistema soporta poca carga.<\/p>\n\n\n\n
Si el rendimiento global se est\u00e1 resintiendo debido a la duraci\u00f3n de los backups, se pueden hacer varios backups cortos para abreviar la duraci\u00f3n total del tiempo dedicado al backup. Una manera de acortar los backups consiste en utilizar la compresi\u00f3n de datos de backup. Otra forma de abreviar la duraci\u00f3n del backup consiste en hacer la copia de seguridad de la base de datos en un disco. Ahora bien, si se hace backup en un disco, no hay que hacerlo en el mismo disco utilizado para guardar la base de datos o el registro de transacciones. De lo contrario, no s\u00f3lo se merma el rendimiento, sino que tambi\u00e9n puede afectar a la posibilidad de recuperaci\u00f3n de la informaci\u00f3n en caso de fallo del disco.<\/p>\n\n\n\n
SQL Server ofrece tres m\u00e9todos de backup b\u00e1sicos: completo, diferencial y de transacciones. Son opciones de backup incorporadas en el propio SQL Server, por lo que no es necesaria una aplicaci\u00f3n de backup independiente. Un backup completo realiza una copia de seguridad de todo. Es el m\u00e1s largo, el que m\u00e1s tarda y el que m\u00e1s recursos utiliza. Un backup diferencial s\u00f3lo copia lo que ha cambiado desde el \u00faltimo backup completo. Esto hace que los backups sean m\u00e1s r\u00e1pidos, pero las restauraciones son m\u00e1s lentas, puesto que es necesario reconstruir la base de datos. Un backup del registro de transacciones s\u00f3lo copia el registro de transacciones desde el backup anterior del mismo. Es muy r\u00e1pido, pero la reconstrucci\u00f3n de una base de datos a partir de una cadena de backups de registros de transacciones es el m\u00e1s lento de los m\u00e9todos de restauraci\u00f3n.<\/p>\n\n\n\n
Adem\u00e1s de estos tres m\u00e9todos de backup de toda la base de datos; SQL Server tambi\u00e9n permite backup individualmente archivos o grupos de archivos, lo cual puede resultar \u00fatil para proteger archivos importantes o para hacer backups de bases de datos muy grandes.<\/p>\n\n\n\n
La selecci\u00f3n del m\u00e9todo de backup m\u00e1s adecuado para cada organizaci\u00f3n depende de la \u00edndole de la base de datos que se desea proteger, y concretamente de la frecuencia con la que cambia, de su tama\u00f1o, y de su importancia para la entidad. Algunas bases de datos no son muy grandes y cambian con relativamente poca frecuencia. Se pueden proteger mediante backups completos realizados diariamente o a intervalos semanales. Otras, en especial las bases de datos de transacciones cr\u00edticas, son objeto de backup completo con la mayor frecuencia viable.<\/p>\n\n\n\n
Aparte de la propia base de datos, el registro de transacciones contiene los datos m\u00e1s cr\u00edticos de una base de datos SQL Server. El registro de transacciones recoge toda la actividad y se puede utilizar para realizar restauraciones hasta un momento determinado (point-in-time, PIT). La ventaja del registro de transacciones es que se puede hacer backup con frecuencia, manteni\u00e9ndolo muy actualizado. Tambi\u00e9n dispone de backups PIT o casi PIT, entre otras m\u00e1s convencionales. Hay que se\u00f1alar que un backup de transacciones s\u00f3lo copia hasta el anterior backup de transacciones. Eso significa que para conseguir una restauraci\u00f3n completa, hay que restaurar una secuencia de backups de transacciones. La fuerza del backup de un registro de transacciones reside en su capacidad de restaurar hasta el minuto anterior, o casi.<\/p>\n\n\n\n
El registro de transacciones se deber\u00eda hacer backup varias veces al d\u00eda. Muchas organizaciones que utilizan una base de datos activa, como una base de datos de transacciones, le hacen backup cada 10 minutos m\u00e1s o menos.<\/p>\n\n\n\n
El otro componente vital de una aplicaci\u00f3n SQL son las bases de datos del sistema, entre ellas msdb y master. Contienen informaci\u00f3n vital, como la configuraci\u00f3n del sistema, y son necesarias en caso de restauraci\u00f3n completa. Cambian con menor frecuencia y se deber\u00edan de hacer backup al menos una vez por semana, o a diario si se trata de un entorno activo (donde las transacciones de datos son frecuentes): En el caso de las bases de datos master, hay que realizar backups al menos cada vez que se produce un cambio en los ajustes a nivel de configuraci\u00f3n del servidor o de la base de datos, o si se introduce cualquier cambio en los detalles de las cuentas de inicio. Se puede copiar las bases de datos del sistema mientras se est\u00e1 ejecutando la aplicaci\u00f3n.<\/p>\n\n\n\n
T\u00e9cnicamente, la partici\u00f3n del sistema no forma parte de SQL Server, pero una partici\u00f3n del sistema sin hacer backup puede dificultar la recuperaci\u00f3n de la base de datos. Es importante mantener un backup actualizado de la partici\u00f3n del sistema, lo cual significa que hay que hacer backup al menos cada vez que se introduzca un cambio en la configuraci\u00f3n del sistema; los backup peri\u00f3dicos son a\u00fan mejores.<\/p>\n\n\n\n
Cerci\u00f3rese de que su base de datos est\u00e1 bien protegida. Por ejemplo, cuando utilice el sistema de archivos para realizar backups, s\u00f3lo debe permitir que accedan las carpetas y archivos la cuenta de servicio de SQL y el administrador de la base de datos.<\/p>\n\n\n\n
En la orden de backup no utilice la opci\u00f3n de contrase\u00f1a para proteger con ella el backup. Ha sido objeto de cr\u00edticas y est\u00e1 previsto que desaparezca en las versiones futuras de SQL Server.<\/p>\n\n\n\n
Cuando realice backups, utilice la opci\u00f3n de suma de comprobaci\u00f3n de la orden de backup y compruebe peri\u00f3dicamente sus backups mediante la orden Comprobar solamente la restauraci\u00f3n.<\/p>\n\n\n\n
Por \u00faltimo, cerci\u00f3rese de que sus parches de seguridad est\u00e9n actualizados y correctamente instalados \u2013 no s\u00f3lo en el servidor SQL, sino tambi\u00e9n en el hardware y el sistema operativo que lo sustentan.<\/p>\n","protected":false},"excerpt":{"rendered":"
Una aplicaci\u00f3n SQL Server en funcionamiento en realidad es una colecci\u00f3n de bases de datos. Adem\u00e1s de los datos en s\u00ed, incluye bases de datos del sistema y el registro de transacciones. Para poder restaurar la aplicaci\u00f3n sin tropiezos, todo esto tiene que estar protegido. A continuaci\u00f3n encontrar\u00e1 algunos consejos y buenas pr\u00e1cticas de Restauraci\u00f3n y backup con SQL Server. … <\/p>\n