COPIA DE SEGURIDAD Y RESTAURACIÓN.

          

  COPIA DE SEGURIDAD Y RESTAURACIÓN:

1.     DEFINICIÓN:

Una copia de seguridad, respaldo, copy backup, copia de respaldo, copia de reserva (del inglés backup) es una copia de los datos originales que se realiza con el fin de disponer de un medio para recuperarlos en caso de su pérdida. Las copias de seguridad son útiles ante distintos eventos y usos: recuperar los sistemas informáticos y los datos de una catástrofe informática, natural o ataque; restaurar una pequeña cantidad de archivos que pueden haberse eliminado accidentalmente, corrompido, infectado por un virus u otras causas; guardar información histórica de forma más económica que los discos duros y además permitiendo el traslado a ubicaciones distintas de la de los datos originales; etc.

Una copia de seguridad completa de una base de datos crea una copia de seguridad de toda la base de datos, Esto incluye la parte del registro de transacciones para poder recuperar la base de datos completa después de restaurar una copia de seguridad completa de la base de datos. Las copias de seguridad completas representan la base de datos en el momento en que finalizó la copia de seguridad.

La copia de seguridad de la base de datos de SQL Server es esencial para proteger los datos.

El componente de copia de seguridad y restauración de SQL Server ofrece una protección esencial para los datos críticos almacenados en las bases de datos de SQL Server. Para minimizar el riesgo de pérdida de datos catastrófica, debe realizar copias de seguridad de las bases de datos para conservar las modificaciones en los datos de forma periódica. Una estrategia de copias de seguridad y restauración correctamente planeada contribuye a la protección de las bases de datos de la pérdida de datos derivada de daños causados por diferentes errores. Pruebe la estrategia mediante la restauración de las copias de seguridad y la posterior recuperación de la base de datos para estar preparado y poder responder de forma eficaz ante un desastre.

 2.     TIPOS:

ü  Copia de seguridad de solo copia:

Copia de seguridad de uso especial independiente de la secuencia normal de copias de seguridad de SQL Server.

ü  Copia de seguridad de datos:

Copia de seguridad de datos de una base de datos completa (copia de seguridad de base de datos), una base de datos parcial (copia de seguridad parcial) o un conjunto de archivos de datos o grupos de archivos (copia de seguridad de archivos).

ü  Copia de seguridad de base de datos:

Copia de seguridad de una base de datos. Las copias de seguridad completas representan la base de datos completa en el momento en que finalizó la copia de seguridad. Las copias de seguridad diferenciales solo contienen los cambios realizados en la base de datos desde la copia de seguridad completa más reciente.

ü  Copia de seguridad diferencial:

Copia de seguridad de datos basada en la última copia de seguridad completa de una base de datos completa o parcial o de un conjunto de archivos de datos o grupos de archivos (base diferencial) y que solo incluye las extensiones de datos que han cambiado desde la última base diferencial.

Una copia de seguridad diferencial parcial únicamente registra las extensiones de datos que han cambiado en grupos de archivos desde la copia de seguridad parcial anterior, que se conoce como la base para la diferencial.

ü  Copia de seguridad completa:

Copia de seguridad completa que incluye todos los datos de una base de datos determinada o un conjunto de grupos de archivos o archivos, así como una cantidad suficiente del registro como para permitir la recuperación de datos.

ü  Copia de seguridad de registros:

Copia de seguridad de los registros de transacciones que incluye todos los registros no guardados en una copia de seguridad de registros anterior. (modelo de recuperación completa).

ü  Copia de seguridad de archivos:

Copia de seguridad de uno o varios archivos de base de datos o grupos de archivos.

ü  Copia de seguridad parcial:

Contiene datos de algunos de los grupos de archivos de una base de datos, incluidos los datos del grupo de archivos principal, todos los grupos de archivos de lectura/escritura, y los archivos de solo lectura opcionalmente especificados.

3.     LIMITACIONES Y RESTRICCIONES:

En estas limitaciones y restricciones, el dispositivo de origen es el dispositivo desde el que se creó la copia de seguridad de la base de datos y el dispositivo de destino, el dispositivo en el que se va a restaurar esa base de datos.

Restaurar una base de datos no vuelve a generar automáticamente las estadísticas.

En el dispositivo solo se puede ejecutar una instrucción RESTORE DATABASE o BACKUP DATABASE en un momento dado. Si se envían varias instrucciones BACKUP y RESTORE al mismo tiempo, el dispositivo las pone en cola y las procesa una a una.

Solo se puede restaurar una copia de seguridad de base de datos en un dispositivo de destino de Almacenamiento de datos paralelos que tenga el mismo número o más nodos de ejecución que el dispositivo de origen. El dispositivo de destino no puede tener menos nodos de ejecución que el de origen.

§  RESTORE no se permite en una transacción explícita o implícita.

§  Las copias de seguridad que se crean en una versión más reciente de SQL Server no se pueden restaurar en versiones anteriores de SQL Server.

§  En SQL Server 2017, puede restaurar una base de datos de usuario a partir de una copia de seguridad de la base de datos creada utilizando SQL Server 2005 o una versión posterior.

En la lista siguiente se describe las operaciones que no se puede realizar en la base de datos maestra de SQL Server.

ü  Realizar una copia de seguridad diferencial de master.

ü  Crear objetos de usuario en master.

ü  Cambiar la intercalación de master.

ü  Cambiar el propietario del maestro.

ü  Quitar o cambiar el nombre de patrón.

ü  Modificar los permisos al maestro.

4.     EJEMPLOS:

Antes de restaurar la base de datos, el administrador de la base de datos debe realizar una copia de seguridad de registros después del error. Puesto que la base de datos está dañada, es necesario usar la opción NO_TRUNCATE al realizar la copia del registro:

BACKUP LOG adb TO tailLogBackup WITH NORECOVERY, NO_TRUNCATE 

Secuencias de Restauración:

ü  Restauración parcial del grupo de archivos principal y secundario A.

RESTORE DATABASE adb FILEGROUP='Primary' FROM backup1  

   WITH PARTIAL, NORECOVERY 

RESTORE DATABASE adb FILEGROUP='A' FROM backup2  

   WITH NORECOVERY 

RESTORE LOG adb FROM backup3 WITH NORECOVERY 

RESTORE LOG adb FROM backup4 WITH NORECOVERY 

RESTORE LOG adb FROM backup5 WITH NORECOVERY 

RESTORE LOG adb FROM tailLogBackup WITH RECOVERY 

ü Restauración con conexión del grupo de archivos C.

En este momento, el grupo de archivos principal y el secundario A están en línea. Todos los archivos de los grupos de archivos B y C están pendientes de recuperación y sin conexión.

Los mensajes de la última instrucción RESTORE LOG del paso 1 indican que la reversión de las transacciones en las que interviene el grupo de archivos C se ha diferido porque este grupo de archivos no está disponible. Las operaciones periódicas pueden continuar, pero estas transacciones mantienen los bloqueos y no se truncará el registro hasta que se pueda completar la reversión.

En la segunda secuencia de restauración, el administrador de la base de datos restaura el grupo de archivos C:

RESTORE DATABASE adb FILEGROUP='C' FROM backup2a WITH NORECOVERY 

RESTORE LOG adb FROM backup3 WITH NORECOVERY 

RESTORE LOG adb FROM backup4 WITH NORECOVERY 

RESTORE LOG adb FROM backup5 WITH NORECOVERY 

RESTORE LOG adb FROM tailLogBackup WITH RECOVERY 

En este momento, los grupos de archivos principal, A y C están en línea. Los archivos del grupo B permanecen pendientes de recuperación, con el grupo de archivos sin conexión. Las transacciones diferidas se han resuelto y se trunca el registro.

ü  Restauración con conexión del grupo de archivos B.

En la tercera secuencia de restauración, el administrador de la base de datos restaura el grupo de archivos B. La copia de seguridad del grupo de archivos B se realizó después de cambiar el grupo a solo lectura, por lo que no es necesario ponerlo al día durante la recuperación.

RESTORE DATABASE adb FILEGROUP='B' FROM backup2b WITH RECOVERY

RESUMEN:

ü  Una estrategia de copia de seguridad y restauración contiene una parte de copia de seguridad y una parte de restauración. La parte de copia de seguridad de la estrategia define el tipo y la frecuencia de las copias de seguridad, la naturaleza y la velocidad del hardware necesaria, cómo se prueban las copias de seguridad, y dónde y cómo se almacenan los medios de copia de seguridad (incluidas las consideraciones de seguridad). La parte de restauración de la estrategia define quién es responsable de llevar a cabo las operaciones de restauración y cómo se deben realizar para satisfacer sus objetivos de disponibilidad de la base de datos y minimizar la pérdida de datos. Se recomienda documentar los procedimientos de copia de seguridad y restauración, y mantener una copia de la documentación en su libro de documentación de procesos.

ü  Diseñar una estrategia de copia de seguridad y restauración eficaz requiere mucho cuidado en el planeamiento, la implementación y las pruebas. Es necesario realizar pruebas. No tendrá una estrategia de copia de seguridad hasta que haya restaurado correctamente las copias de seguridad en todas las combinaciones incluidas en su estrategia de restauración. Debe tener en cuenta varios factores. Entre ellas, figuran:

ü Los objetivos de producción de la organización para las bases de datos, especialmente los requisitos de disponibilidad y protección de datos frente a pérdidas.

ü La naturaleza de cada una de las bases de datos: el tamaño, los patrones de uso, la naturaleza del contenido, los requisitos de los datos, etc.

ü Restricciones de los recursos, como hardware, personal, espacio para almacenar los medios de copia de seguridad, seguridad física de los medios almacenados, etc.

ü  Las operaciones de copias de seguridad y restauración se producen en el contexto de un modelo de recuperación. El modelo de recuperación es una propiedad de la base de datos que controla la forma en que se administra el registro de transacciones. Además, el modelo de recuperación de una base de datos determina qué tipos de copias de seguridad y qué escenarios de restauración se admiten para la base de datos. Normalmente, en las bases de datos se usa el modelo de recuperación simple o el modelo de recuperación completa. El modelo de recuperación completa puede complementarse cambiando al modelo de recuperación optimizado para cargas masivas de registros antes de las operaciones masivas.

ü  La mejor elección de modelo de recuperación para la base de datos depende de sus requisitos empresariales. Para evitar la administración del registro de transacciones y simplificar la realización de copias de seguridad y restauración, utilice el modelo de recuperación simple. Para minimizar el riesgo de pérdida de trabajo, a costa de una sobrecarga de trabajo administrativo, utilice el modelo de recuperación completa.

SUMMARY:

ü  A backup and restore strategy contains a backup part and a restoration part. The backup part of the strategy defines the type and frequency of backups, the nature and speed of the necessary hardware, how backup copies are tested, and where and how backup media are stored. (including security considerations). The restoration part of the strategy defines who is responsible for carrying out the restoration operations and how they should be performed to meet their database availability objectives and minimize data loss. It is recommended that you document the backup and restore procedures, and keep a copy of the documentation in your process documentation book.

ü  Designing an effective backup and restoration strategy requires great care in planning, implementation and testing. It is necessary to perform tests. You will not have a backup strategy until you have successfully restored the backup copies in all the combinations included in your restore strategy. You must take into account several factors. Among them, they include:

ü  The production objectives of the organization for the databases, especially the requirements of availability and data protection against losses.

ü  The nature of each of the databases: the size, the patterns of use, the nature of the content, the requirements of the data, etc.

ü  Restrictions of resources, such as hardware, personnel, space to store backup media, physical security of stored media, etc.

ü  Backup and restore operations occur in the context of a recovery model. The recovery model is a property of the database that controls the way in which the transaction log is managed. In addition, the recovery model of a database determines what types of backups and what restore scenarios are supported for the database. Normally, the simple recovery model or the full recovery model is used in the databases. The full recovery model can be complemented by changing to the optimized recovery model for massive loads of records before mass operations.

ü  The best choice of recovery model for the database depends on your business requirements. To avoid managing the transaction log and simplifying backup and restore, use the simple recovery model. To minimize the risk of job loss, at the cost of administrative work overload, use the full recovery model.

RECOMENDACIONES:

ü  Se recomienda no adjuntar ni restaurar bases de datos de orígenes desconocidos o que no sean de confianza.

ü  Restaurar la base de datos maestra conlleva restaurar la información de inicio de sesión del dispositivo.

ü  Coloque la base de datos y las copias de seguridad en dispositivos separados. De lo contrario, si se produce un error en el dispositivo que contiene la base de datos, las copias de seguridad no estarán disponibles. El hecho de colocar la base de datos y las copias de seguridad en distintos dispositivos también mejora el rendimiento de E/S de la escritura de las copias de seguridad y el uso de producción de la base de datos.

CONCLUCIONES:

Debido a las amenazas de pérdida y corrupción de datos debido al error humano o a las tentativas de estafa, así como a los daños del hardware o desastres naturales (como incendios o inundaciones), es imperativo garantizar la seguridad de datos, guardando y haciendo copias de seguridad de su información esencial en más destinos y utilizando más de un método.

Cada empresa ha sufrido o está en riesgo de sufrir una pérdida de datos debido a un error humano, a un daño en el hardware que contiene los datos guardados localmente, a causa de desastres naturales como inundaciones, terremotos o incendios (situaciones frecuentes en el mundo en los últimos años). Todos estos eventos destruirían cualquier empresa que no haya creado copias de seguridad de sus datos y los haya guardado lejos de su propia empresa.

Es información vital para el funcionamiento de una organización y su pérdida puede llevar a la quiebra de la empresa. Por eso es tan importante realizar periódicamente un backup de los datos utilizando uno o varios tipos de copias de seguridad según la estrategia de respaldo aplicada. 

APRECIACIÓN DEL EQUIPO:

ü  A medida que la base de datos aumenta de tamaño, las copias de seguridad completas requieren una mayor cantidad de tiempo para finalizar y espacio de almacenamiento. Por ello, para una base de datos grande, puede que desee complementar una copia de seguridad completa.

Para decidir con qué frecuencia debe realizar copias de seguridad, considere la frecuencia con la que se cambia la base de datos:

ü  Si la base de datos es una base de datos de archivo, o se utiliza sólo como referencia y apenas cambia, debe realizar una copia de seguridad cada vez que cambien los datos.

ü  Si la base de datos está activa y los datos cambian frecuentemente, debe realizar una copia de seguridad según una programación.

ü  Si la base de datos no contiene datos, sino que utiliza tablas vinculadas, debe hacer copia de seguridad de la base de datos cada vez que cambie su diseño.

GLOSARIO DE TÉRMINOS:

ü  Restaurar: Cargar a una base de datos uno o varios objetos de una base de datos desde una copia de seguridad de esa base de datos o de esos objetos. La restauración sobrescribe cualquier información de la base de datos con la información de la copia de seguridad. Después de restaurar una base de datos, deberá recuperarla.

ü  Recuperar: Devolver una base de datos restaurada a un momento dado consistente anterior al momento en que se produjo el daño o fallo. Las bases de datos de Oracle Server se deben restaurar antes de recuperarlas. Una vez que la base de datos se haya restaurado y recuperado correctamente, estará lista para su uso. Puede realizar recuperaciones tanto automáticas como manuales.

ü  RESTORE DATABASE: Restaura copias de seguridad realizadas con el comando BACKUP.

ü  BACKUP DATABASE: Es el proceso de realizar una copia de seguridad, permite la creación de una instancia o copia duplicada de una base de datos en caso de que la base de datos principal falle, se dañe o se pierda.

ü  NO_TRUNCATE: Compacta los datos en los archivos de datos moviendo las páginas asignadas desde el final de un archivo a las páginas no asignadas en la parte frontal del archivo. NOTRUNCATE solo es aplicable a archivos de datos. El archivo de registro no se ve afectado.

LINKOGRAFÍA:

ü  https://docs.microsoft.com/es-es/sql/analytics-platform-system/master-database?view=aps-pdw-2016

ü  https://docs.microsoft.com/es-es/sql/t-sql/statements/restore-database-parallel-data-warehouse?view=aps-pdw-2016

ü  https://docs.microsoft.com/es-es/sql/relational-databases/backup-restore/back-up-and-restore-of-system-databases-sql-server?view=sql-server-2017

ü  https://docs.microsoft.com/es-es/sql/relational-databases/backup-restore/restore-a-database-backup-using-ssms?view=sql-server-2017

ü  https://es.slideshare.net/LisbethOcaaBueno/copia-de-seguridad-y-restauracipn