Capítulo 1. Riesgos para tus datos: Por qué hacemos copias de seguridad

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Tú podrías pensar que no necesitas este capítulo. Ya sabes por qué hacemos copias de seguridad de los datos, y no necesitas que nadie te convenza de que hacer copias de seguridad es algo importante. Sin embargo, puede que haya algunas razones para hacer copias de seguridad en las que quizá no hayas pensado. Te serán útiles en las reuniones que empiecen con la pregunta: "¿Por qué gastamos tanto dinero en copias de seguridad y recuperación ante desastres?".

Nota

A nadie le importa si puedes hacer copias de seguridad. Sólo si puedes restaurar.

-Sr. Respaldo

Este capítulo abarca una serie de razones por las que necesitamos copias de seguridad y recuperación ante desastres (DR), enumeradas en el orden en que es más probable que ocurran. Empecemos por la razón más común por la que te encontrarás buscando tu manual de copias de seguridad: Alguien ha hecho algo mal. Puede que un desastre natural no sea probable en tu caso, pero un desastre humano seguro que sí.

Catástrofes humanas

La mayoría de las restauraciones y recuperaciones de desastres de hoy en día se ejecutan porque los humanos hacen algo, accidentalmente o a propósito, que daña tu entorno informático. Puede ser cualquier cosa, desde un simple error de dedo gordo hasta un ataque terrorista que acabe con todo tu edificio. Puesto que esta actividad es tan común, es de lo que tus sistemas de copia de seguridad y recuperación ante desastres deben ser realmente buenos para recuperarse.

En primer lugar, describiré un grupo de desastres causados accidentalmente, y luego pasaré a actos más malintencionados que también quieren dañar tus datos. A continuación, completaré esta sección con cómo protegerte contra la amenaza a tus datos desde dentro.

Accidentes

La gente comete errores. A veces copias el archivo equivocado en el lugar equivocado y sobrescribes un archivo bueno con otro malo. A veces intentas hacer sitio para nuevos datos y borras un montón de archivos y vacías la papelera, sólo para darte cuenta segundos después de que has borrado algo que no querías borrar.

Como persona que ha trabajado frente a un teclado durante la mayor parte de su vida, no puedo decirte el número de veces que he tocado algo con los dedos gordos y he causado un daño increíble con sólo pulsar unas pocas teclas. Esto es lo que algunos llamamos PEBKAC, como en "Existe un problema entre el teclado y la silla".

A menudo, cuando pensamos en lo que llamamos error del usuario, tendemos a pensar en lo que nuestro sector llama el usuario final, o la persona o personas que utilizan realmente los sistemas y bases de datos que proporciona el departamento de informática. Es muy fácil pensar que todos los errores de los usuarios proceden de ellos, no de nosotros. Pero la realidad es que los administradores de sistemas, redes y bases de datos también son bastante falibles.

De hecho, los administradores no sólo cometen errores como los demás, sino que sus errores pueden tener ramificaciones mucho mayores. He visto cientos de ejemplos de esto en mi carrera. He aquí una lista rápida que me viene a la cabeza.

  • Elimina la tabla incorrecta de una base de datos.

  • Formatear la unidad equivocada, borrando un sistema de archivos en perfecto estado.

  • Realiza una restauración de una base de datos de desarrollo en una base de datos de producción.

  • Escribe un script diseñado para borrar los directorios personales huérfanos, pero que en realidad borre todos los directorios personales.

  • Elimina la máquina virtual (VM) equivocada.

Los que tenemos privilegios de administrador blandimos una poderosa espada. Un ligero balanceo en la dirección equivocada puede ser mortal. Esa es otra de las razones por las que damos marcha atrás.

Código Malo

El código malicioso puede venir de cualquier parte. Puede ser algo tan simple como un script de shell que se vuelve demasiado entusiasta y borra los datos equivocados, o puede ser un error real en el núcleo del software que corrompe los datos silenciosamente. Estas historias no suelen salir en las noticias, pero ocurren todo el tiempo.

Tal vez se trate de un desarrollador interno que no sigue reglas básicas, como dónde colocar su código. Recuerdo hace años cuando todo un equipo de desarrollo de una docena o así de desarrolladores internos almacenaba todo su árbol de código en /tmp en un sistema HP-UX, donde /tmp se almacenaba en RAM. El código era maravilloso hasta que alguien reinició el servidor y /tmp se limpió junto con todo lo demás de la RAM.

El software comercial desarrollado por un equipo profesional de desarrolladores tampoco es inmune. Una vez más, no sólo su software se ejecuta a menudo a un nivel privilegiado y, por tanto, es capaz de hacer mucho daño, sino que el mismo software se está ejecutando en cientos o miles de organizaciones. A veces no se advierte un error hasta que ha hecho bastante daño.

Mi anécdota favorita para ilustrar esto es la de una versión de un determinado paquete comercial de software de copia de seguridad cuyo desarrollador quería agilizar la colocación de una etiqueta electrónica en la parte frontal de cada cinta. Había dos quejas sobre el antiguo proceso, la primera de las cuales era que una cinta que se reutilizaba -y, por tanto, se volvía a etiquetar electrónicamente- requería pulsar varios botones para asegurarse de que realmente se quería sobrescribir esa cinta con una nueva etiqueta electrónica. La segunda era que el proceso sólo utilizaba una unidad de cinta cada vez, aunque hubiera varias unidades de cinta en la biblioteca de cintas. La última versión del software introdujo lo que llamaron la opción "rápida y silenciosa". Esto significaba que etiquetaría tantas cintas como quisieras, sin preguntarte si debías sobrescribirlas, utilizando tantas unidades de cinta disponibles como tuvieras.

Esta nueva función vino acompañada de un nuevo error. Antes, cuando veías una lista de cintas y hacías doble clic en una de ellas, aparecía un cuadro de diálogo y te preguntaba si querías sobrescribir esa cinta. Pero ahora, al hacer doble clic en una sola cinta, aparecía un cuadro de diálogo con una lista de todas las cintas de la biblioteca.

Al igual que la combinación de error de usuario y código defectuoso que me hizo perder una versión de este capítulo, un usuario que pensara que estaba sobrescribiendo una cinta se encontraría a dos clics de ratón de sobrescribir todas las cintas de la biblioteca de cintas sin que se lo pidieran, mientras utilizaba todas las unidades de cinta disponibles para que este proceso fuera lo más rápido posible.

Estuve en una reunión con un cliente sentado junto a un consultor enviado por el proveedor del software, que hizo exactamente eso. Quería reetiquetar una sola cinta de la biblioteca de cintas del cliente, así que hizo doble clic en esa cinta, probablemente como hacía siempre. Vio la nueva opción rápida y silenciosa y la eligió. Pasaron varios minutos antes de que se diera cuenta de lo que había hecho, que era sobrescribir todas las cintas de la biblioteca de cintas del cliente, inutilizándolas. Sí, el cliente tenía copias externas de todas esas cintas, así que no perdieron ningún dato. No, no fueron muy comprensivos.

Este es un buen lugar para hablarte de la regla 3-2-1, que es: tres versiones de tus datos, en dos soportes diferentes, una de las cuales se almacena en algún lugar.

Nota

La regla 3-2-1 es la regla fundamental en la que se basan todas las copias de seguridad. La trataré con más detalle en el Capítulo 3, pero la verás mencionada en casi todos los capítulos.

La gente comete errores. A veces la gente buena hace cosas malas que borran o corrompen los datos, y ésta es otra razón por la que hacemos copias de seguridad .

Ataques malintencionados

Veamos ahora el segundo tipo de riesgo para los datos: gente mala haciendo cosas malas. Los ataques maliciosos contra tu centro de datos se han convertido, por desgracia, en algo bastante habitual. Por eso, los verdaderos enemigos del centro de datos moderno son los malos actores empeñados en hacer daño a tu organización mediante algún tipo de ataque electrónico. Ármate de valor; esto puede ponerse un poco entrecortado.

Terrorismo

Alguien puede elegir como objetivo a tu organización a propósito y causar daños físicos de alguna manera. Puede intentar volar tus edificios, incendiarlos, estrellar aviones contra ellos o cometer todo tipo de acciones terroristas físicas. Puede ser con fines políticos, como ocurrió el 11-S, o por sabotaje empresarial. Esto último es menos probable, pero puede ocurrir y ocurre.

Proteger tu infraestructura del terrorismo queda fuera del ámbito de este libro. Simplemente quería mencionar que el terrorismo es otra razón más por la que existe la regla 3-2-1. Haz copias de seguridad de tus datos y aléjalas de los datos que estás protegiendo.

Por desgracia, el 11-S varias organizaciones dejaron de existir porque no siguieron la regla 3-2-1. Tenían copias de seguridad. Incluso disponían de centros de RD listos para tomar el relevo en cualquier momento, en la otra torre. Por eso, cuando hablamos del "1" en la regla 3-2-1, nos referimos a lejos. Una copia replicada sincrónicamente de tu base de datos en un servidor situado a unos cientos de metros no es un buen plan de RD.

Ataques electrónicos

Lo más habitual es que tu organización sufra algún tipo de ataque electrónico. Aunque podría ser a través de alguien que piratee tu cortafuegos y abra una puerta trasera en tu centro de datos, es más probable que sea algún tipo de malware que se introduzca en tu entorno informático. Ese malware abre entonces la puerta desde dentro.

Vi una charla de un experto en seguridad que hacía demostraciones en directo sobre cómo hackear organizaciones. Ninguna de ellas era mediante cortafuegos explotados, ni nada por el estilo. Todas explotaban alguna vulnerabilidad humana para conseguir que le abrieras la puerta trasera. La verdad es que daba bastante miedo.

Este tipo de malware suele introducirse mediante algún tipo de phishing y/o mecanismo de ingeniería social que hace que alguien de tu organización descargue el código errante directamente en tu entorno informático. Puede ser un correo electrónico, un sitio web pirateado o incluso una llamada telefónica a la persona equivocada. (En el discurso mencionado anteriormente, un vector de ataque era un cable de carga de teléfono que desplegaba malware si lo conectabas a un ordenador que permitía datos en ese puerto USB). Una vez que se produce esa penetración inicial, el malware puede propagarse por diversos medios a toda la organización.

ransomware

El malware más común que anda suelto estos días es lo que llamamos ransomware. Una vez dentro de tu sistema, cifra los datos de forma silenciosa y, finalmente, te ofrece una clave de descifrado a cambio de una suma económica (es decir, un rescate). Este rescate puede ser de unos cientos de dólares si eres un particular o de millones de dólares si eres una gran organización.

Los ataques de ransomware van en aumento, y las peticiones de rescate no han hecho más que crecer. Esta tendencia continuará hasta que todas las organizaciones descubran la respuesta sencilla a un ataque de este tipo: un buen sistema de RD.

Por eso hablo del ransomware con más detalle en el Capítulo 11. Creo que el ransomware es la razón número uno por la que realmente podrías necesitar utilizar tu sistema de RD. Es mucho más probable que te sorprenda un ataque de ransomware que una catástrofe natural o que un administrador deshonesto borre tus datos. Y la única respuesta válida a ello es un sistema de RD con un breve tiempo de recuperación.

El malware y el ransomware son un problema desde hace tiempo. Esto se debe en parte a que los ataques de ransomware se limitaban a quienes tenían los medios técnicos para llevarlos a cabo, pero ya no es así. Esto está cambiando con la llegada de los proveedores de ransomware como servicio (RaaS), que hacen que sea mucho más fácil entrar en el juego del ransomware.

Tú especificas el objetivo y cualquier información útil para acceder a dicho objetivo, y ellos ejecutan el ataque. Estas organizaciones criminales lo hacen únicamente con fines lucrativos, porque se llevan una parte significativa de cualquier beneficio del ataque. Tienen poco interés en otros usos para el ransomware o theftware.

RaaS es relevante para este debate porque refuerza mi afirmación de que esto se está convirtiendo en un peligro mayor para tus datos que cualquier otra cosa. Los hackers cualificados que piratean tu organización por motivos altruistas o de espionaje corporativo han existido desde que los ordenadores aparecieron en escena, pero su número era limitado. Para que fueras susceptible de sufrir un ataque de este tipo, necesitarías a alguien con suficientes incentivos para atacarte y suficientes conocimientos sobre cómo hacerlo. La existencia de RaaS elimina ese último requisito. El único conocimiento que necesita ahora un atacante es cómo entrar en la web oscura y ponerse en contacto con un servicio de este tipo.

Lo que quiero decir es lo siguiente: Además de que las catástrofes naturales son más frecuentes que nunca debido al cambio climático, los ataques de ransomware supondrán un riesgo mayor para tus datos cada día que pase. Son una razón más para realizar copias de seguridad.

Pero las amenazas externas, como las catástrofes naturales y los ataques electrónicos, no son tu único problema. Debes tener en cuenta el riesgo de tu propio personal. Echemos un vistazo a las amenazas internas a tus datos.

Amenazas internas

Muchas organizaciones de no se preparan adecuadamente para los ataques que vienen de dentro, en su propio detrimento. Los profesionales de la seguridad de la información advierten repetidamente que muchos ataques proceden del interior. Incluso si un ataque no se inicia desde dentro, podría activarse desde dentro, como por ejemplo si un empleado inocente hace clic accidentalmente en el archivo adjunto de un correo electrónico equivocado.

La amenaza interna más común es un empleado o contratista con acceso privilegiado que se disgusta de alguna manera y decide perjudicar a la organización. El daño puede ser cualquier cosa, desde dañar las operaciones o los datos simplemente por despecho, hasta utilizar su acceso para facilitar un ataque de ransomware.

Es lo que se conoce como el problema del administrador deshonesto. Una persona con acceso privilegiado puede hacer bastante daño sin que nadie se entere. Incluso puede plantar código que haga daño después de marcharse.

Estoy pensando en Yung-Hsun Lin, el administrador de Unix que instaló lo que se denominó una "bomba lógica" en 70 servidores de su organización en 2004. El script en cuestión estaba configurado para destruir todos los datos de los servidores como represalia si le despedían. Aunque sus temores de ser despedido resultaron infundados, dejó la bomba lógica instalada de todos modos. Por suerte, se descubrió antes de que fuera a explotar y no llegó a causar ningún daño. Fue condenado en 2006.

También pienso en Joe Venzor, cuyo ataque premeditado a los datos de su organización provocó semanas de retraso a un fabricante de botas. Temiendo que le despidieran, introdujo una puerta trasera disfrazada de impresora. Fue efectivamente despedido, e inmediatamente activó su malware. Detuvo toda la fabricación una hora después de su despido.

Mientras investigaba para esta sección, me topé con una discusión en Internet en la que una persona sarcástica decía que lo que Joe Venzor hizo mal fue hacer las cosas de tal manera que le permitieran ser descubierto. Lo que debería haber hecho, decía esta persona, era poner en marcha el ataque y hacer que comprobara continuamente si esta persona se conectaba. (Si la persona no se conectaba durante más de un mes, el ataque se iniciaría y llevaría a cabo lo que el atacante quisiera hacer para castigar a la organización.

Esto ilustra el poder que pueden tener los administradores del sistema si se lo permites. Por eso debes hacer todo lo posible por limitar el radio de acción de quienes tienen acceso privilegiado.

El acceso sin restricciones de a la cuenta de administrador en Windows, o a la cuenta de root en Unix y Linux, o a cuentas similares en otros sistemas, puede permitir fácilmente a un administrador deshonesto hacer daño sin rendir cuentas. Haz todo lo que puedas para limitar la capacidad de las personas de acceder directamente como estas cuentas, incluyendo todas las ideas siguientes.

Utiliza cuentas nominativas para todo

Todos los usuarios de deben iniciar sesión como ellos mismos todo el tiempo. Si tienes que utilizar privilegios de root o administrador, debes iniciar sesión como tú mismo y luego obtener dichos privilegios mediante un mecanismo registrado. Limita o elimina las herramientas que deban ejecutarse como root o Administrator.

No des a nadie la contraseña de root

He trabajado en organizaciones que establecen la contraseña de root o de administrador en una cadena aleatoria que nadie registra. La idea es que si necesitas acceso de administrador o root, siempre puedas concederte ese acceso a ti mismo a través de sistemas como sudo o Run as Administrator. Esto te permite hacer tu trabajo pero registra todas tus actividades.

Eliminar o desactivar programas con acceso al shell

Esto es más un problema de Unix/Linux, pero hay muchos comandos (por ejemplo, vi) que admiten el escape al shell. Si puedes ejecutar vi como root, podrás ejecutar cualquier comando como root sin que se registre. Por eso, quienes se preocupan por este problema sustituyen vi por un comando similar que no tenga ese acceso.

Permitir el inicio de sesión de superusuario sólo en la consola

Otra forma de limitar el acceso irrestricto de superusuarios en es permitir sólo ese acceso desde la consola. Esto no es lo ideal, pero es mejor que nada. Luego asegúrate de que se registra cualquier acceso físico a la consola. Esto funciona igual de bien en un mundo de consola virtual, donde la gente debe iniciar sesión en la consola virtual cuando accede.

Registro fuera del host

Cualquier acceso a una cuenta de superusuario (autorizado o no) debe registrarse como un incidente de seguridad, y cualquier información relacionada (por ejemplo, registros de videovigilancia o de la consola virtual) debe almacenarse inmediatamente de forma que un hacker no pueda eliminar las pruebas. De ese modo, si alguien compromete un sistema, no podrá borrar fácilmente sus huellas.

Limitar el arranque desde medios alternativos

Tanto como puedas, elimina la posibilidad de arrancar el servidor o la máquina virtual desde medios alternativos. El motivo es que si puedes arrancar desde medios alternativos, cualquier administrador de Linux o Windows puede arrancar fácilmente el servidor, montar la unidad de arranque y editar cualquier configuración que se encuentre en su camino.

Me estoy centrando en las cosas que una persona de protección de datos debe hacer para ayudar a proteger los datos. También deberías trabajar con un profesional de la seguridad de la información, que es otra disciplina totalmente distinta, y queda fuera del alcance de este libro.

Separación de poderes

Una vez que convierta en norma iniciar sesión como uno mismo al realizar tareas administrativas, el siguiente obstáculo a superar es que demasiadas personas tienen acceso a herramientas todopoderosas que pueden hacer tanto daño como bien. Por ejemplo, si un empleado tiene la capacidad de iniciar sesión como administrador-incluso a través de sudo o similares- puede hacer mucho daño antes de ser detenido. Si esa misma persona también tiene acceso al sistema de copias de seguridad, puede obstaculizar o eliminar la capacidad de la organización para recuperarse de sus acciones.

Por eso hay buenos argumentos para separar esos poderes tanto como sea posible. Los sistemas de copia de seguridad y DR deben ser tu última línea de defensa, y debe gestionarlos una entidad completamente distinta que no tenga también la capacidad de dañar la infraestructura que está protegiendo.

Administración basada en funciones

Una manifestación del concepto de separación de poderes puede verse en las funciones de administración basadas en roles de muchos productos de protección de datos. La idea es que distintas partes del sistema de protección de datos sean gestionadas por distintas personas que, en realidad, tienen distintos poderes que se definen como roles.

Un rol puede ser el de operaciones diarias, por lo que sólo puede ejecutar tareas predefinidas. Por ejemplo, este rol puede monitorizar el éxito de las políticas de copia de seguridad y volver a ejecutar una determinada política de copia de seguridad si falla. Lo que no puede hacer es modificar en modo alguno la definición de esa copia de seguridad. Otro rol tendría la capacidad de definir políticas de copia de seguridad, pero no de ejecutar dichas políticas. Separar la configuración de las copias de seguridad de las operaciones de copia de seguridad minimiza lo que una persona puede hacer.

Una función completamente distinta podría ser la de restauración. En un mundo perfecto, esta función podría limitarse de tal modo que sólo permitiera restaurar los datos en el lugar desde el que se hizo la copia de seguridad. Las restauraciones de servidores alternativos y directorios alternativos requerirían una autorización especial para evitar que esta persona utilizara esta función para exfiltrar datos de la organización.

Los productos de copia de seguridad que incorporan el concepto de administración basada en funciones ya han definido estas funciones, y tú sólo tienes que asignarlas a personas diferentes. Lo que quiero decir es que pienses detenidamente cómo hacerlo. Lo fácil sería asignar todas las funciones a una sola persona, igual que es más fácil dar a todo el mundo la contraseña de root/admin; sin embargo, lo mejor desde el punto de vista de la seguridad es dar a varias personas una única función dentro del sistema de copia de seguridad. Tendrían que colaborar con otra persona de la organización para hacer algo fuera de su función. Aunque esto no elimina por completo la idea de un trabajo interno, reduce significativamente las posibilidades de que se produzca.

Menor privilegio

Una vez que hayas activado la administración basada en roles, asegúrate de que cada persona y cada proceso tengan sólo el nivel de acceso que necesitan para hacer su trabajo. Un ejemplo de esto es no conceder acceso completo de administrador al agente de copia de seguridad que estás instalando. Averigua el nivel de acceso más bajo que necesita para hacer su trabajo, y utiliza ese rol o nivel de acceso. Lo mismo ocurre con los operadores o administradores. Sólo deben tener el nivel de acceso necesario para realizar su trabajo, y nada más.

Autenticación multipersona

Ya que estoy en con la idea de proteger a tu organización de las amenazas internas, me gustaría introducir un concepto que no se encuentra en la mayoría de los productos de copia de seguridad: la autenticación multipersona. Es una versión de la autenticación multifactor que requiere que dos personas autentiquen una actividad concreta. A veces se denomina autenticación de cuatro ojos, porque requiere dos pares de ojos. (Aunque como persona que debe llevar gafas, este término no es mi favorito.) Esta función podría activarse en partes del sistema de copia de seguridad en las que la seguridad sea una preocupación.

Si vas a hacer algo nefasto, puede que quieras borrar todas las copias de seguridad anteriores de un servidor o aplicación determinados, reducir el periodo de retención de cualquier otra copia de seguridad, e incluso borrar por completo la configuración de la copia de seguridad. En la mayoría de los entornos de copia de seguridad, ¡podrías hacer todo eso sin hacer saltar ninguna alarma! Lo mismo ocurre con las restauraciones. Si alguien quiere robar tus datos, puede utilizar fácilmente el sistema de copia de seguridad para restaurar todos esos datos en una ubicación de la que pueda sacarlos fácilmente. Por eso algunos productos exigen la autenticación de dos personas para las restauraciones, los cambios en una política de copias de seguridad o la reducción del periodo de conservación de una copia de seguridad existente.

Al igual que todo lo demás tratado en este capítulo, la autenticación de dos personas no es infalible. Un pirata informático que haya accedido a tu sistema de comunicación podría interceptar y eludir fácilmente las solicitudes adicionales de autenticación. No hay informática sin riesgos; el trabajo del sistema de protección de datos es reducir esos riesgos tanto como sea posible. Por eso, amigos míos, hacemos copias de seguridad de .

Fallo mecánico o del sistema

Cuando entré en el sector de la protección de datos a principios de los noventa, ésta era la razón número uno por la que realmente utilizábamos nuestro sistema de copia de seguridad para el fin previsto. Los sistemas de archivos y las bases de datos se asentaban directamente en discos duros físicos, y cuando uno de esos discos duros decidía darse un chapuzón, se llevaba consigo sus datos.

Las cosas son muy diferentes hoy en día por varias razones, la primera de las cuales es que la mayoría de los datos de misión crítica se almacenan ahora en algún tipo de soporte de estado sólido. Casi todos los datos de perímetro también se almacenan en dichos medios, incluidos los ordenadores portátiles, los teléfonos inteligentes y las tabletas, y los dispositivos del Internet de las Cosas (IoT). El resultado es que el informático medio de hoy simplemente no ha experimentado el nivel de fallos de dispositivos que experimentamos en su día.

Además de que los dispositivos de almacenamiento son cada vez más resistentes, los sistemas de almacenamiento redundante como RAID y la codificación de borrado se han convertido en la norma en cualquier centro de datos que se preocupe por sus datos. Los fabricantes de unidades de disco también parecen incorporar comprobaciones de integridad en el firmware de sus dispositivos que pecan de conservadores para evitar mejor la pérdida de datos debida a un disco averiado. Esto significa que casi nunca se realiza una restauración debido al fallo de un disco duro, pero eso no quiere decir que esas cosas no ocurran.

Incluso en una matriz RAID o de codificación de borrado que pueda gestionar varios fallos de disco simultáneos, estos fallos pueden producirse. Las fuentes de alimentación pueden fallar, o algún firmware puede provocar fallos en varios discos. Es increíblemente raro que un fallo de disco simultáneo acabe con una matriz RAID, pero no es algo inaudito. Por eso el RAID y/o la codificación de borrado no eliminan la necesidad de hacer copias de seguridad. Las restauraciones debidas a estos fallos son raras, pero ocurren.

Interrupciones del suministro eléctrico

Por mucho que odie seguir utilizando como ejemplo el lugar donde vivo, actualmente estamos sufriendo lo que llamamos apagones continuos. Estamos en temporada de incendios, y las compañías eléctricas utilizan los apagones continuos para ayudar a reducir la posibilidad de incendios.

Esto es algo para lo que puedes diseñar fácilmente, y deberías poder sobrevivir desde el punto de vista de la protección de datos. Cualquier centro de datos de un tamaño decente tiene energía redundante y un gran generador. Puedes capear una interrupción razonablemente grande del suministro eléctrico, suponiendo que sepas que se va a producir.

Lo que puede ocurrir, sin embargo, es una interrupción inesperada del suministro eléctrico. Si toda la energía que llega a tu centro de datos se detiene sin previo aviso, todos tus servidores dejarán de funcionar. Los datos no se guardarán correctamente y parte de ellos podrían corromperse. La mayoría de los datos estructurados deberían poder sobrevivir gracias a las funciones de integridad de datos incorporadas, y la mayoría de los datos no estructurados deberían sobrevivir, excepto unos pocos archivos en proceso de escritura en el momento del corte. Además, mientras que una base de datos puede sobrevivir gracias a sus funciones de integridad de datos, el proceso de recuperación de medios (tratado en el Capítulo 7) puede tardar más que una restauración completa.

Hay varios "debería" en el párrafo anterior, por eso hacemos copias de seguridad. A veces las bases de datos no vuelven a funcionar tras la caída de un servidor. A veces, el archivo que se estaba escribiendo cuando se fue la luz era un archivo realmente importante en el que la gente ha estado trabajando durante varios días. Por eso hacemos copias de seguridad.

No Hay Nube

Por muy fan que sea de la nube pública, en realidad no es más que envoltorio y marketing. No existe la nube; sólo existe el ordenador de otra persona. Sí, han hecho todo tipo de programación para que la nube sea fácil de aprovisionar y administrar y para que sea más resistente en general. Pero la nube no es mágica; es sólo un montón de ordenadores que te prestan un servicio. Esos ordenadores pueden fallar, al igual que las unidades de disco que contienen.

También es importante darse cuenta de que no todo el almacenamiento en la nube es igual desde el punto de vista de la protección de datos. Aunque el almacenamiento de objetos suele replicarse en varias ubicaciones y, por tanto, puede sobrevivir a diversas calamidades, la mayor parte del almacenamiento de bloques es simplemente un número de unidad lógica (LUN) en una unidad virtual de una única matriz de almacenamiento en un único centro de datos. No ofrece ningún tipo de redundancia y, por tanto, hay que hacer copias de seguridad. El almacenamiento en bloque redundante está disponible en la nube, pero la mayoría de la gente no utiliza esa opción. Además, como se verá más adelante en este capítulo, la redundancia no resuelve los problemas causados por los humanos.

Fallo del sistema

Tanto si estamos hablando de un único servidor con una única matriz de almacenamiento, de un clúster metropolitano que abarca varios centros de datos y ubicaciones geográficas, o de un servicio que se utiliza en la nube, nada es perfecto. Los programadores cometen errores y ocurren cosas malas. Por eso hacemos copias de seguridad de los datos que realmente importan.

En una ironía para acabar con todas las ironías, un error de programación combinado con un error del usuario me hizo perder por completo la primera versión de este capítulo. Como se menciona en otras partes del libro, estoy escribiendo este libro utilizando el software de dictado Dragon mientras camino sobre una cinta en medio de una pandemia. La configuración por defecto de Dragon es guardar el audio de tu dictado automáticamente, junto con el propio documento, y esto hace que guardar el documento lleve mucho más tiempo. Como nunca había utilizado el audio, esta mañana en concreto decidí cambiar la configuración y decirle que me preguntara antes de guardar el audio.

Dicté durante unas dos horas mientras caminaba en la cinta, y entonces recordé de repente que no había estado guardando a medida que avanzaba, como hago normalmente. Dije: "Haz clic en Archivo... Guardar", que activa el proceso de guardado. Apareció un cuadro de diálogo que me preguntaba si quería guardar el documento, pero por alguna razón pensé que me estaba preguntando si quería guardar el audio. Respondí: "No", y procedió a cerrar el documento sin guardarlo. Ahí se fueron dos horas de dictado.

Debería haber prestado más atención al responder al cuadro de diálogo, y no debería haber cerrado el archivo que no le dije que cerrara. Simplemente le dije a Dragon que lo guardara y luego le dije que no lo guardara; nunca le dije que lo cerrara. Lo que quiero decir es que el software y el hardware pueden no hacer lo que esperas que hagan, y por eso hacemos copias de seguridad. Este es un mal ejemplo, porque las copias de seguridad no servirían de nada en este caso; simplemente, todo el documento estaba en la RAM. Ni siquiera un producto de protección continua de datos (PCD) habría ayudado en esta situación.

Nota

La mayoría de los consejos que se dan en este libro deberían aplicarse a cualquier entidad comercial, gubernamental o sin ánimo de lucro que utilice ordenadores para almacenar datos vitales para el funcionamiento de esa organización. Por eso, siempre que sea posible, utilizaré la palabra organización para referirme a la entidad protegida. Puede tratarse de un gobierno, una organización no gubernamental (ONG), una empresa privada o pública con ánimo de lucro o una empresa sin ánimo de lucro.

Siendo la resiliencia del sistema y del almacenamiento lo que es hoy en día, la pérdida de datos debida a un fallo físico del sistema no debería ocurrir demasiado a menudo. Sin embargo, poco puede hacer tu organización para detener la siguiente amenaza a tus datos de la que hablaremos. Si un desastre natural golpea a tu organización, será mejor que estés preparado.

Catástrofes naturales

Dependiendo de dónde vivas, y de la suerte que tenga tu organización, es posible que ya hayas experimentado una o más catástrofes naturales que intentaron acabar con tus datos. De hecho, debido al increíble nivel de resistencia del hardware actual, es mucho más probable que sufras un desastre natural que un fallo mecánico o del sistema.

Las catástrofes naturales son una de las grandes razones por las que la regla 3-2-1 es tan importante, y por las que ésta no será la última vez que hable de ella en este libro. Es especialmente importante si vas a utilizar tu sistema de copia de seguridad para RD.

La clave para sobrevivir a una catástrofe natural es planificar y diseñar tu sistema de RD en función de los tipos de catástrofes que pueden afectar a tu zona y, por tanto, a tus datos. Echemos un vistazo a varios tipos de catástrofes naturales para ver a qué me refiero. Pido disculpas de antemano a mi audiencia internacional; todos mis ejemplos estarán basados en Estados Unidos. Asumo que tú tienes catástrofes naturales similares donde vives.

Inundaciones

Inundaciones puede acabar con tu centro de datos y ocurrir por diversas razones. Tal vez el sistema de aspersores de tu edificio funcione mal e inunde tu edificio de agua. Tal vez tu tejado tenga una gotera y caiga un fuerte aguacero; ahí van tus servidores. O tal vez vivas en una llanura aluvial, y un río gigante se desborde y se lleve tu edificio con él. El resultado es el mismo: los ordenadores y el agua no se llevan bien.

Hice mis primeros refuerzos en Delaware, junto al río Delaware. No nos preocupaban demasiado los huracanes, salvo que uno que subiera por la costa podría provocar una gran tormenta que causara una inundación en el río Delaware. Nuestros centros de datos estaban en la planta baja, y eso era un problema. Combínalo con el hecho de que nuestra instalación de almacenamiento externo de medios estaba en un búnker de la II Guerra Mundial que en realidad era subterráneo.

Cuando se trata de inundaciones, el terreno elevado es algo hermoso. Al igual que en las otras catástrofes regionales mencionadas anteriormente, la clave está en asegurarte de que tu emplazamiento de RD está completamente fuera de donde pueda haber una inundación. Dependiendo de tu localidad, en realidad podría estar relativamente cerca, pero en un terreno más elevado. Como en todo lo demás, consulta a un experto en estas cosas antes de tomar una decisión.

Incendios

En California tenemos cuatro estaciones: fuego, inundación, barro y sequía. Es un clima desértico, y no hace falta mucho para provocar un incendio forestal. Una vez fuera de control, esos incendios forestales son su propio ser vivo y es casi imposible detenerlos. Yo he tenido que evacuar debido a un incendio al menos una vez, porque un gran incendio forestal estaba ardiendo fuera de control y se dirigía directamente hacia mi casa. (Si miras el mapa de ese incendio, tenía la forma de un triángulo gigante. La punta de ese triángulo apuntaba directamente a mi casa). El fuego se acercó a pocos kilómetros de nosotros, pero al final tuvimos suerte.

Pero puede que no sea un incendio forestal lo que acabe con tu centro de datos. Podría ser algo tan simple como un cortocircuito eléctrico en una sola caja. Por eso tenemos disyuntores, pero no siempre funcionan. Tal vez alguien guarde demasiados trapos aceitosos en el lugar equivocado y se produzca una combustión espontánea. Tal vez alguien tire un cigarrillo por la ventana y se cree un incendio cerca de tu edificio antes de que lo detengas. Los incendios son increíblemente perjudiciales para un centro de datos. Igual que el agua y los ordenadores no se mezclan, tampoco lo hacen los ordenadores y el humo.

Existen diversos métodos fuera del ámbito de la copia de seguridad y la DR para sobrevivir a un incendio en un centro de datos. Pero lo más probable es que, si tienes uno, estés deseando tener un sólido plan de copia de seguridad y DR. Por tanto, el fuego es otra razón más para hacer copias de seguridad.

Terremotos

Vivo en el sur de California, así que estoy muy familiarizado con los terremotos. Para los que no vivís aquí, os ruego que comprendáis que la mayoría de los terremotos son increíblemente leves y sólo se sienten como si estuvieras sentado en una gran cama vibratoria durante unos segundos. No recuerdo la última vez que un terremoto en mi zona fue lo bastante fuerte como para hacer caer algo de la estantería, y mucho menos para causar daños reales. El terremoto de Northridge, en Los Ángeles (a 160 km de mí), es el terremoto importante más reciente de la historia, y fue en 1994.

La clave para sobrevivir a un terremoto es la preparación. Los edificios se construyen para sobrevivir a terremotos leves, y las normas de construcción exigen que las cosas del interior de esos edificios estén sujetas con correas. Incluso dentro de mi casa, por ejemplo, mi calentador de agua requiere una correa. Los bastidores de los centros de datos se colocan sobre soportes amortiguados que permiten que el bastidor se mueva un poco si el suelo tiembla. Probablemente esto te suene completamente extraño si no vives aquí, pero es una parte muy estándar del diseño de edificios y centros de datos en California.

También tienes que pensar en el daño que puede causar un terremoto y asegurarte de que la copia DR de tus datos está fuera del radio de explosión de ese daño. En realidad, esto no es tan difícil de hacer, porque los terremotos suelen ser muy localizados. Consulta a un experto en terremotos y te asesorará a este respecto.

Huracanes, tifones y ciclones

Los huracanes, los tifones y los ciclones son tormentas mortales que se forman sobre el agua. (Los huracanes se llaman tifones en el Pacífico Norte occidental, y ciclones en el Océano Índico y el Pacífico Sur). Crecí en Florida y he pasado bastante tiempo en la costa del Golfo de Texas, así que también conozco un poco los huracanes. Los miembros de mi familia y yo hemos estado en medio de múltiples huracanes y al margen de muchos más. A diferencia de un terremoto típico, lo bueno de un huracán es que te avisan con un poco de antelación. También tienes un conocimiento sólido de los tipos de daños que puede causar un huracán, dependiendo de dónde vivas. Puedes enfrentarte a mareas de tempestad, que provocan inundaciones. Puedes sufrir daños en tejados o edificios. Simplemente tienes que diseñar tu plan de respuesta ante desastres en función de estos problemas.

La verdadera clave para sobrevivir a un huracán es asegurarte de que tu plan de RD se basa en utilizar un sistema que esté completamente fuera de la trayectoria de cualquier huracán potencial. Esto significa no situar tu centro de RD en ningún lugar de la costa sureste de Estados Unidos ni en ningún lugar de la costa del Golfo. Los huracanes pueden ser increíblemente impredecibles y llegar a cualquier punto de la costa de esas regiones. Como veremos en el capítulo sobre DR, creo que la mejor opción para sobrevivir a un huracán es un sistema de DR basado en la nube, porque te permitiría tener tu sitio de DR en cualquier otra parte del país, incluso en cualquier otra parte del mundo.

Tornados

Tornados son remolinos de viento mortales de potencia extremadamente concentrada. En Estados Unidos tenemos lo que se llama el callejón de los tornados, donde los tornados son frecuentes. Incluye partes de nueve estados, empezando por el norte de Texas y extendiéndose hasta Dakota del Sur. Para los que no estén familiarizados con los tornados, se trata de fenómenos increíblemente concentrados que pueden eliminar por completo toda evidencia de un edificio y dejar completamente intacto el edificio de al lado. Combinan las peores fuerzas de un huracán con la imprevisibilidad de un terremoto, porque un tornado puede caer de la nada en cuestión de segundos.

Al igual que los huracanes, la clave para sobrevivir a los tornados es un centro de RD que no esté situado en ningún lugar del callejón de los tornados. Tal vez puedas argumentar que los tornados son fenómenos tan concentrados que un emplazamiento de RD en, digamos, Dakota del Sur, puede proteger un centro de datos en, digamos, Kansas. Pero no sé por qué, puestos a elegir, harías eso. Mi opinión personal sería tenerlo en algún lugar muy al oeste o al este de donde estés.

Socavones

Discuto mucho con mis padres sobre qué estado tiene los peores desastres naturales: Florida o California. Les digo que todos los años hay huracanes que azotan Florida, pero que los grandes terremotos son increíblemente raros en California. Ellos replican que los huracanes te avisan con cierta antelación y te permiten prepararte, mientras que los terremotos golpean sin previo aviso. La baza son los socavones. No sólo golpean sin apenas aviso, sino que pueden causar daños increíbles en muy poco tiempo. Combinan la naturaleza de ataque quirúrgico de los tornados con el aspecto de alerta cero de los terremotos. Los supervivientes de un tornado te dirán que suena como un tren de mercancías mientras ocurre; los socavones son completamente silenciosos, excepto por los enormes daños que causan. ¡Qué miedo!

Para los que no estén familiarizados con este fenómeno, que es bastante común en Florida y no desconocido en otras partes del mundo, se debe a que los cimientos de piedra caliza se asientan sobre gigantescos embalses submarinos. Estos ríos y lagos subterráneos corren por toda Florida y a menudo se explotan como fuente de agua dulce. Si drenas toda el agua dulce de un embalse concreto, creas un punto débil en la piedra caliza. Es un castillo de naipes y puede llevarse al instante algo tan pequeño como un dormitorio o tan grande como varias manzanas de una ciudad.

Vi un documental en el que se hablaba de camas de personas que eran succionadas por sumideros mientras dormían. También mencionaba el socavón más infame que ocurrió a 15 minutos de donde yo vivía: el socavón de Winter Park de 1981. Una tarde, varias manzanas de la ciudad se hundieron en la tierra a cientos de metros de profundidad, para no volver a verse nunca más, llevándose por delante una casa, la piscina comunitaria y un concesionario de Porsche.

A riesgo de repetirme, asegúrate de que tu sitio DR no está cerca de tu sitio principal. Los socavones son relativamente raros desde el punto de vista del número de socavones por milla cuadrada, pero ocurren continuamente . Es una razón más para asegurarte de que sigues la regla 3-2-1, que explicaré en detalle en el Capítulo 3.

Para llevar

Hay innumerables razones para hacer copias de seguridad de nuestros datos importantes y asegurarnos de que están protegidos de cualquier daño. La primera razón es que lo que no se ha respaldado no se puede restaurar. Recuerda, no les importa si puedes hacer una copia de seguridad; sólo les importa si puedes restaurarla.

El mundo no ha sido amable con quienes no hacen copias de seguridad. Catástrofes naturales, terroristas, piratas informáticos y simples accidentes de nuestro propio personal figuran en la lista. Además, por muy fiables que se hayan vuelto la informática y el almacenamiento en las últimas décadas, ni la fiabilidad ni la resiliencia detienen a un huracán o a un hacker. De lo único que te protege el hardware resistente es de los fallos del hardware, no de las cosas que atacan a los propios datos o hacen estallar todo el centro de datos.

En resumen, la copia de seguridad, la recuperación y la RD son ahora más importantes y más complejas que nunca. Por eso es más importante que nunca acertar con nuestros requisitos antes de diseñar un sistema de protección de datos, y por eso el siguiente capítulo trata precisamente de eso.

Get Protección de datos moderna now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial