Este artículo es parte de una serie sobre la construcción de NAS y está escrito para un tipo específico de sistema.

La copia de seguridad es la segunda tarea principal que quería resolver usando el NAS, después del sistema de administración del repositorio .

Su decisión se prolongó ...

Ya se han escrito muchos artículos e incluso varios libros sobre este tema, y ​​muchas copias se han roto en disputas al respecto.

A continuación hay un intento de descubrir este montón de material, ponerlo en su cabeza y construir un sistema pequeño de manera relativamente competente.

El sistema de respaldo (SRK) está determinado por:

• Política de respaldo. La política establece las principales metas y objetivos de la copia de seguridad, los requisitos para ella, en función de la lista de amenazas para cada sistema de copia de seguridad, y también justifica su necesidad.
• Regulaciones de respaldo basadas en políticas. La regulación describe los algoritmos de respaldo y recuperación responsables de los respaldos, las condiciones de almacenamiento de los respaldos, etc.
• Implementación instrumental. En realidad, software y hardware.

El proceso de copia de seguridad regular se divide en las siguientes partes principales:

• Inicio periódico de la copia.
• Comience la recuperación bajo demanda.
• Probar el proceso de copia.

Puntos de interfaz del sistema con la plataforma NAS:

• tank0/apps/backup : almacenamiento de tank0/apps/backup .
• tank1/apps/backup : almacenamiento de tank1/apps/backup .
• https://backup.NAS.cloudns.cc : interfaz del sistema basada en la web.

Los repositorios de respaldo son sistemas de archivos separados .
Esto es necesario porque sus opciones pueden ser muy diferentes, tanto de los sistemas de archivos normales como entre ellos.

Por ejemplo, si es necesario, se puede habilitar la deduplicación mediante FS y se puede deshabilitar la compresión.

Principios de respaldo

Vale la pena entender que, aunque describo aquí un caso especial de respaldo que se adapta a las necesidades de una red pequeña, los principios, observaciones y patrones son comunes en todas partes.
En casos simples, algunos de ellos pueden ser descuidados, pero es deseable saberlo.

Estos principios se basan en políticas y regulaciones.

Aquí hay algunos básicos:

• 3-2-1 . Realice al menos tres copias de seguridad, en dos formatos de almacenamiento, de las cuales al menos una debe almacenarse en un lugar físicamente separado. El principio es deseable de observar. En mi caso, este principio se implementa parcialmente. En primer lugar, hay tres máquinas diferentes en las que los datos se duplican parcialmente: NAS, trabajo y computadora portátil. En segundo lugar, se planea la replicación a la nube.
• Verifique lo que se ha copiado . De lo contrario, puede suceder que en un momento crucial, los datos no se puedan restaurar. Verifique mejor a través del proceso de recuperación.
• Use las herramientas adecuadas para la tarea . Es probable que con la copia de una flota de máquinas virtuales, un sistema para copiar archivos con un agente en una máquina funcione mal. El software especializado copiará más rápido y menos costoso en los recursos de la máquina. Es importante que la herramienta sea confiable y simple. El SII no es algo con lo que generalmente quieras cavar.
• Es mejor copiar todo, con la obvia excepción del exceso . O "es mejor adelantar que no terminar". Será posible descartar el exceso, pero si se utiliza la política inversa, puede ser imposible restaurar un archivo valioso que olvidó especificar explícitamente.
• Debería ser posible seleccionar y restaurar datos rápidamente . Es recomendable, "un clic", y no esperar una hora. Formalmente, debe tener un RTO aceptablemente bajo y un RPO suficiente. Es extremadamente conveniente si el SII le permite restaurar accidentalmente eliminado y elegir entre varias versiones, y no solo la última (por ejemplo, si está dañado, porque los errores lógicos no están excluidos).

Al final del artículo hay enlaces a fuentes que puede estudiar para familiarizarse más con estos puntos, así como leer sobre otros.

Política de respaldo

Obviamente, el objetivo de cualquier copia de seguridad es reducir el costo de la destrucción de datos no planificada en situaciones de emergencia.

Esto se logra mediante la duplicación de datos valiosos de máquinas en funcionamiento al almacenamiento de terceros.

Tareas de respaldo

Las siguientes tareas se definen con fines de copia de seguridad:

• Resalta los datos del objetivo.
• Guardar los datos especificados para su posterior recuperación.
• Recuperación de datos guardados.
• Garantizar la estabilidad de los datos almacenados ante cambios y destrucción.
• Diferenciación de acceso a datos almacenados.
• Proporcionar control del sistema y proceso de respaldo.

Requisitos del sistema

Además en la lista, se combinan los requisitos funcionales y no funcionales:

• La copia de seguridad debe realizarse:
  
  • A tiempo
  • Previa solicitud
  • Si te saltas el anterior.
• La copia de seguridad de datos debe proporcionarse al menos 1 vez por día a una profundidad de 1 mes. La práctica de tomar instantáneas, así como usar la versión anterior del sistema en una máquina que funciona, muestra que esto es suficiente para mí.
• El tiempo de recuperación de datos no debe exceder los 2 minutos por 1 GB (el límite de ancho de banda de la red es de 81 s. Por 1 GB). Tomado en cuenta el ancho de banda LAN y la velocidad del disco, como factores limitantes.
• Todos los canales deben estar encriptados. Se pueden guardar datos confidenciales, como los datos de autorización en servicios en línea.
• Debería ser posible cifrar las copias de seguridad de los usuarios con una clave secreta en la máquina del usuario, sin la posibilidad de descifrarlas en el servidor. Esto es importante porque los usuarios no están obligados a confiar en el servidor en absoluto.
• La copia incompleta no debería llevar mucho tiempo, por ejemplo, más de 30 minutos. Internet se utiliza para copiar datos de una computadora portátil.
• Debe existir la posibilidad de replicar copias en la nube (la capacidad de configurar de manera flexible la replicación para un almacenamiento en la nube en particular) con cifrado de copias de seguridad. Esta es también una de las consecuencias del "principio 3-2-1".
• Debe haber una gestión centralizada simple con integración en la interfaz web.
• Un mínimo de mejoras y configuraciones complejas en el servidor.

Composición de recursos reservados

En mi caso, es bastante típico:

• La principal máquina de trabajo. Computadora de escritorio
• Máquina de trabajo móvil. El portatil.
• Enrutador LAN. Almacena configuraciones de red, que pueden contener inicios de sesión y contraseñas para una conexión a Internet y algunos servicios.
• NAS Sí, la configuración del NAS también es redundante. A pesar de que la mayoría de los FS tienen instantáneas.

Composición de amenazas

Aquí es dónde, qué y qué debe protegerse y de qué manera.

Todas las principales amenazas a la computadora móvil repiten las amenazas a la estacionaria.
Las tabletas prácticamente no difieren de las móviles, desde este punto de vista.

Términos de política adicionales

Es recomendable tenerlos en cuenta:

• Se deben realizar pruebas de recuperación periódicas.
• Los procedimientos de recuperación de fallas deben documentarse.
• Las acciones deben regularse en caso de una falla secundaria: qué hacer si, después de la restauración, el sistema no está operativo o los datos no se pueden restaurar.
• Es necesario comprobar si el proceso de recuperación depende de un equipo específico.
  (que puede fallar en el momento de la recuperación). Yo, en mi caso, no comprobaré esto, limitado a solo una comprobación básica del sistema.
• Si tiene una copia de seguridad completa del sistema, debe realizar una copia de seguridad inmediatamente después de una actualización sustancial.
• Si el volumen acumulado de las copias de seguridad incrementales excede el volumen de la copia de seguridad completa, es racional hacer una copia de seguridad completa no programada. Es decir, la frecuencia de crear copias de seguridad completas debería aumentarse en este caso.

No tomo en cuenta el último punto de la política, porque generalmente mi flujo de trabajo no cambia, y es suficiente para monitorear el volumen por un tiempo, solo para la configuración inicial.
Empíricamente, se descubrió que el esquema "mes, semana, día, hora" está bastante bien para mí.
Para sistemas más grandes, es posible que deba cambiar la frecuencia de respaldo dinámicamente para cada sistema.

Regulaciones de respaldo

Después del desarrollo de una política, es posible proceder directamente con el desarrollo de una regulación.
En el caso general, puede haber varias regulaciones: generales, para los administradores de IBS, para los usuarios, para los responsables del almacenamiento, para los administradores de los sistemas de destino, etc.
Pero en el caso de un sistema pequeño, generalmente es una persona y, por lo tanto, solo hay una regulación.

Los objetivos de la normativa.

• Definición de procedimientos de respaldo de datos.
• Definición de procedimientos de recuperación de datos.
• Definición de un procedimiento de verificación del estado del sistema.
• Condiciones de almacenamiento de respaldo y requisitos de medios.
• Agilización del trabajo.

Ejemplo de regulación

Bajo el spoiler, puede ver cómo se ven las reglas en una organización grande, utilizando el ejemplo de la regulación de Rosreestr tomada de fuentes abiertas .

Aquí encontrarás otro ejemplo con una breve descripción.

Procedimiento de reserva

Composición de los datos de respaldo:

• Máquinas de trabajo:
  
  • Directorios de usuarios personales ( /home/* ). .
  • .
  • , ( /opt ).
  • ( /etc ).
  • .
  • .
  • .
  • .
• :
  
  • .
• NAS:
  
  • Docker .
  • .
  • .
  • .
  • .
  • Docker .
  • .
  • .
• :
  
  • .

:

• .
• , .
• /etc/apt/apt.conf.d , , .
• Mikrotik .
• NAS .

:

• 1 . .
  3 .
• 1 .
  .
• 1 .
  .
• .
  .
• .
  6 , .

• , .
• , .

:

• live .
• .
• , .

, Debian ( Squeeze 2011 ), Slackware ReiserFS .

:

• , .
• .
• , .
• .

Mikrotik , RouterOS .

• .
  logcheck, .
• .

, .

• .
• 1 .
  .
• . .
• .

, .

:

• Veeam , , . , Acronis, , .
• .
• .

.
, .

UrBackup .
, .

.

UrBackup

, :

 # zfs create -o com.sun:auto-snapshot=false -p tank0/apps/backup # zfs set compression=on tank0/apps/backup 

, , UrBackup ZFS .

, :

 # zfs set dedup=on tank0/apps/backup 

UrBackup :

 # mkdir /tank0/docker/services/urbackup # cd /tank0/docker/services/urbackup # vim docker-compose.yml # docker-compose up -d 

docker-compose .
Web- .

 version: '2' networks: docker0: external: name: docker0 services: urbackup: uroni/urbackup-server image: restart: always expose: - 55414 ports: # - 55413:55413 - 55415:55415 - 35623:35623/udp volumes: - /tank0/apps/backup/urbackup/database:/var/urbackup - /tank0/apps/backup/urbackup/backups:/backups - /tank0/apps/backup/urbackup/log:/var/log - /etc/localtime:/etc/localtime:ro networks: - docker0 environment: - VIRTUAL_HOST=backup.* - VIRTUAL_PORT=55414 - VIRTUAL_PROTO=http - CERT_NAME=NAS.cloudns.cc - TZ=Europe/Moscow 

Docker uroni/urbackup-server , tristanteu/urbackup-docker .
.

, :

1. . UrBackup LDAP .
2. LDAP. LDAP . " ". , .
3. .
4. , . . . , NAS, .
5. -.

:

:

LDAP , : , .

:

 ou=users,dc=nas,dc=nas?memberOf,objectClass?sub?(&(memberOf=cn=users_backup,ou=groups,dc=nas,dc=nas)(uid={USERNAME})) 

- , .

, , .
, :

-:

, , .

, UrBackup:

• TCP 55415 — .
• TCP 55414 — Web- HTTP.
• TCP 55413 — Web- FastCGI, Web-. Porque NAS HTTP/HTTPS, .
• TCP 35621 — .
• UDP 35622 — . . .
• TCP 35623 — .
• UDP 35623 — .

, 55415 , 35621, 35622, 35623 .

, .

:

• , shell .
• GUI , .
• Docker- .

UrBackup , .. , :

.

shell :

 TF=`mktemp` && wget "https://NAS.system.cloudns.cc/x?a=download_client&lang=ru&clientid=1&authkey=KEY&os=linux" -O $TF && sh $TF; rm $TF 

:

 ~# urbackupclientctl status { "capability_bits": 65548, "finished_processes": [], "internet_connected": true, "internet_status": "connected", "last_backup_time": 0, "running_processes": [], "servers": [], "time_since_last_lan_connection": 152446032 } 

NAS , :

• : /etc;/home;/var;/root;/tank0/apps;/tank0/docker .
• : /tank0/apps/backup;/tank1/apps/backup;/tank0/apps/cloud/nextcloud/html/data .

, , , , , .

, , , " ", , :

:

 ~# service urbackupclientbackend status ● urbackupclientbackend.service - UrBackup Client backend Loaded: loaded (/lib/systemd/system/urbackupclientbackend.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-09-30 21:55:53 MSK; 37min ago Main PID: 1694 (urbackupclientb) Tasks: 14 (limit: 4915) Memory: 13.4G CGroup: /system.slice/urbackupclientbackend.service └─1694 /usr/local/sbin/urbackupclientbackend --config /etc/default/urbackupclient --no-consoletime  30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/   .djvu"  30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/  .doc"  30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/-.fb2" 

Los problemas

, UrBackup , . .
— -, .

 ~# service urbackupclientbackend status ● urbackupclientbackend.service - UrBackup Client backend Loaded: loaded (/lib/systemd/system/urbackupclientbackend.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-09-30 20:36:54 MSK; 9s ago Main PID: 27034 (urbackupclientb) Tasks: 10 (limit: 4915) Memory: 6.1M CGroup: /system.slice/urbackupclientbackend.service └─27034 /usr/local/sbin/urbackupclientbackend --config /etc/default/urbackupclient --no-consoletime  30 20:36:54 host urbackupclientbackend[27034]: urbackupserver: Server started up successfully!  30 20:36:54 host urbackupclientbackend[27034]: FileSrv: Server started up successfully  30 20:36:54 host urbackupclientbackend[27034]: Started UrBackupClient Backend...  30 20:36:55 host urbackupclientbackend[27034]: Looking for old Sessions... 2 sessions  30 20:36:56 host urbackupclientbackend[27034]: Trying to connect to internet server "NAS.system.cloudns.cc" at port 55415  30 20:36:56 host urbackupclientbackend[27034]: Successfully connected.  30 20:36:56 host urbackupclientbackend[27034]: ERROR: Internet server auth failed. Error: Auth failed (Authkey/password wrong)  30 20:36:56 host urbackupclientbackend[27034]: InternetClient: Had an auth error  30 20:36:56 host urbackupclientbackend[27034]: ERROR: Internet server auth failed. Error: Auth failed (Authkey/password wrong)  30 20:36:56 host urbackupclientbackend[27034]: InternetClient: Had an auth error 

:

 ERROR: Internet mode not enabled. Please set "internet_mode_enabled" to "true". 

.

:

 ~# service urbackupclientbackend stop ~# rm -rf /usr/local/var/urbackup/ 

/etc/default/urbackupclient , .

, /usr/local/var/urbackup/data/settings.cfg .

, , :

 internet_server=NAS.system.cloudns.cc internet_server_port=55415 internet_authkey=44R3MUIdB computername=zenbook internet_mode_enabled=true 

, , -.
, , , .

Debian, , /etc/apt/apt.conf.d/80full-backup :

 DPkg::Post-Invoke {"test -x /usr/local/bin/urbackupclientctl && /usr/local/bin/urbackupclientctl start -f || true"; }; 

NAS, . , mtbackup SSH, NAS.
Python , , , UrBakup, .

:

• .
• .

, : . , .

, :

• .
• , .
• .
• , , .
• .
• .
• , .

, - , .

.
, , .
- , , Storj .

, , :

• debian-russian . , " rsync?".
• " " .
• " 3-2-1" Veeam .
• .
• , , , .
• Veeam .
• " " , , .
• " : " .
• , .
• .

, :

• W. Curtis Preston — "Backup & Recovery" — 2000 .
• .. — .
• . — Backup "" — 2014 .
• Steven Nelson — Pro Data Backup and Recovery — 2011 .
• Dorian Cougias — The Backup Book: Disaster Recovery from Desktop to Data Center, 3 edition — 2003 .
• (2017 ) .

.

, RTO, RPA, RPO. , , , .

- NAS , , , .