A copia de seguridade non é unha das tecnoloxías de moda que se gritan dende todos os ferros. Só ten que ser en calquera empresa seria, iso é todo. Facemos unha copia de seguranza de varios miles de servidores do noso banco: este é un traballo complexo e interesante, do que só queremos que nos digan algunhas das sutilezas, así como os típicos equívocos sobre as copias de seguridade.
Levo case 20 anos traballando neste tema, dos cales os últimos 2 anos foron en Promsvyazbank. Ao comezo da práctica, fixen copias de seguridade case manualmente, con scripts que simplemente copiaban ficheiros. Entón apareceron ferramentas convenientes en Windows: a utilidade Robocopy para preparar ficheiros e NT Backup para copiar. E só entón chegou o momento do software especializado, principalmente Veritas Backup Exec, que agora se chama Symantec Backup Exec. Entón, estou familiarizado coas copias de seguridade dende hai moito tempo.
En termos sinxelos, a copia de seguridade é manter unha copia dos datos (máquinas virtuais, aplicacións, bases de datos e ficheiros) por se con certa regularidade. Cada caso adoita manifestarse como un fallo de hardware ou lóxico e provoca a perda de datos. O obxectivo dun sistema de copia de seguridade é reducir a perda de información. Un fallo de hardware é, por exemplo, un fallo do servidor ou do almacenamento onde se atopa a base de datos. Lóxico: esta é a perda ou o cambio de parte dos datos, incluso debido ao factor humano: eliminaron accidentalmente unha táboa, un ficheiro, lanzaron un script malo para a súa execución. Tamén hai requisitos reguladores para almacenar un determinado tipo de información durante un longo período, por exemplo, ata varios anos.
O uso máis típico das copias de seguridade é a restauración dunha copia gardada de bases de datos para a implantación de varios sistemas de proba, clons para desenvolvedores.
Hai algúns mitos típicos sobre as copias de seguridade que deberían ser eliminados hai moito tempo. Aquí están os máis famosos deles.
Mito 1. A copia de seguridade foi durante moito tempo só unha pequena función dentro dos sistemas de seguridade ou de almacenamento
Os sistemas de copia de seguridade seguen sendo unha clase separada de solucións e moi independentes. Teñen moito traballo que facer. De feito, son a última liña de defensa cando se trata de integridade dos datos. Entón, a copia de seguridade funciona ao seu propio ritmo, segundo o seu propio horario. Xérase un informe diario para os servidores, hai eventos que actúan como disparadores para o sistema de monitorización.
Ademais, o modelo de acceso ao sistema de copia de seguridade permítelle delegar parte da autoridade aos administradores dos sistemas de destino para xestionar as copias de seguridade.
Mito 2. Cando hai un RAID, xa non é necesaria unha copia de seguridade.
Sen dúbida, as matrices RAID e a replicación de datos son unha boa forma de protexer os sistemas de información de fallos de hardware e, se tes un servidor en espera, podes organizar rapidamente o cambio a el en caso de que falle a máquina principal.
Dos erros lóxicos que cometeron os usuarios do sistema, a redundancia e a replicación non se salvan. Aquí tes un servidor en espera de reescritura: si, pode axudarche se se detecta un erro antes de sincronizalo. E se se perde o momento? Só unha copia de seguridade oportuna axudará aquí. Se sabes que os datos cambiaron onte, podes restaurar o sistema antes de onte e extraer os datos necesarios. Dado o feito de que os erros lóxicos son os máis comúns, a boa copia de seguridade antiga segue a ser unha ferramenta comprobada e necesaria.
Mito 3. Unha copia de seguridade é algo que se fai unha vez ao mes.
A frecuencia de copia de seguridade é unha configuración configurable que depende principalmente dos requisitos do sistema de copia de seguridade. É moi posible atopar datos que case nunca cambian e non son especialmente importantes, a súa perda non será crítica para a empresa.
De feito, pódense facer copias de seguranza unha vez ao mes e aínda con menos frecuencia. Pero os datos máis críticos gárdanse con máis frecuencia, dependendo do indicador RPO (obxectivo do punto de recuperación), que establece a perda de datos permitida. Isto pode ser unha vez por semana, unha vez ao día ou incluso varias veces por hora. Temos estes rexistros de transaccións do DBMS.
Cando os sistemas se poñan en funcionamento comercial débese aprobar a documentación de copias de seguridade na que se reflictan os puntos principais, o procedemento de actualización, o procedemento de restauración do sistema, o procedemento de almacenamento de copias de seguridade, etc.
Mito 4. O volume de copias está en constante crecemento e ocupa completamente calquera espazo asignado.
As copias de seguranza teñen un período de retención limitado. Non ten sentido, por exemplo, almacenar as 365 copias de seguridade diarias durante o ano. Como regra xeral, é aceptable manter copias diarias durante 2 semanas, despois das cales substitúense por outras novas e a versión que se fixo primeiro durante o mes permanece en almacenamento a longo prazo. Á súa vez, tamén se almacena durante un tempo determinado: cada copia ten unha vida útil.
Hai protección contra a perda de datos. Aplícase a regra: antes de que se elimine unha copia de seguridade, hai que formar a seguinte. Polo tanto, os datos non se eliminarán se non se completou a copia de seguridade, por exemplo, debido á indisponibilidade do servidor. Non só se respectan os prazos, senón que tamén se controla o número de copias do conxunto. Se o sistema está deseñado para ter dúas copias de seguridade completas, sempre haberá dúas delas, e a antiga só eliminarase cando se escriba con éxito unha terceira nova. Polo tanto, o crecemento do volume ocupado polo arquivo de copia de seguranza está asociado só co crecemento da cantidade de datos protexidos e non depende do tempo.
Mito 5. Comezou a copia de seguranza: todo colgado
É mellor dicir isto: se todo está colgado, entón as mans do administrador non crecen a partir de aí. En xeral, o rendemento dunha copia de seguridade depende de moitos factores. Por exemplo, sobre a velocidade do propio sistema de copia de seguridade: o rápido que son os almacenamentos de discos, as bibliotecas de cintas. Desde a velocidade dos servidores do sistema de copia de seguridade: se teñen tempo para procesar datos, realizar compresión e deduplicación. E tamén sobre a velocidade das liñas de comunicación entre o cliente e o servidor.
A copia de seguranza pode ir a un ou máis fluxos, dependendo de se o sistema que se está a realizar a copia de seguranza admite o multithreading. Por exemplo, o DBMS de Oracle permítelle dar varios fíos, segundo o número de procesadores dispoñibles, ata que a taxa de transferencia alcance o límite de ancho de banda da rede.
Se tentas facer unha copia de seguranza dun gran número de fíos, entón existe a posibilidade de sobrecargar un sistema en execución, realmente comezará a ralentizarse. Polo tanto, escóllese o número óptimo de fíos para garantir un rendemento suficiente. Se ata a mínima diminución do rendemento é crítica, entón hai unha excelente opción cando a copia de seguridade non se realiza desde un servidor de combate, senón desde o seu clon: en espera na terminoloxía da base de datos. Este proceso non inicia o sistema de traballo principal. Os datos pódense recuperar a través de máis fluxos, xa que o servidor non se utiliza para o mantemento.
Nas grandes organizacións, créase unha rede separada para o sistema de copia de seguridade para que a copia de seguridade non afecte á produción. Ademais, o tráfico pode non transmitirse a través da rede, senón a través da SAN.
Tentamos repartir a carga tamén no tempo. As copias de seguridade realízanse principalmente en horario non laborable: pola noite, os fins de semana. Ademais, non todos corren ao mesmo tempo. As copias de seguridade das máquinas virtuais son un caso especial. O proceso practicamente non ten ningún efecto sobre o rendemento da propia máquina, polo que a copia de seguridade pódese repartir durante o día e non aprazar todo pola noite. Hai moitas sutilezas, se tes todo en conta, a copia de seguridade non afectará o rendemento dos sistemas.
Mito 6. Lanzou un sistema de copia de seguridade: iso é tolerancia a fallos para ti
Non esquezas nunca que un sistema de copia de seguridade é a última liña de defensa, o que significa que debería haber cinco sistemas máis diante del que garantan a continuidade, a alta dispoñibilidade e a tolerancia aos desastres da infraestrutura de TI e dos sistemas de información empresarial.
Esperar que a copia de seguridade restaure todos os datos e eleve rapidamente o servizo caído non paga a pena. Garántese a perda de datos desde o momento da copia de seguridade ata o momento do fallo, e os datos pódense cargar a un novo servidor durante varias horas (ou días, segundo teñas sorte). Polo tanto, ten sentido crear sistemas completos tolerantes a fallos sen cambiar todo a unha copia de seguridade.
Mito 7. Configurei unha copia de seguridade unha vez, comprobei que funciona. Só queda mirar os rexistros
Este é un dos mitos máis prexudiciais, cuxa falsidade só te das conta durante o incidente. Os rexistros de copia de seguridade exitosos non son unha garantía de que todo saíu como debería. É importante comprobar a copia gardada para a súa implementación con antelación. É dicir, inicia o proceso de recuperación nun ambiente de proba e mira o resultado.
E un pouco sobre o traballo do administrador do sistema
No modo manual, ninguén estivo copiando datos durante moito tempo. Os SRK modernos poden facer unha copia de seguranza de case todo, só tes que configuralo correctamente. Se se engadiu un servidor novo, configure políticas: seleccione o contido do que se fará unha copia de seguranza, especifique as opcións de almacenamento e aplique a programación.
Ao mesmo tempo, aínda hai moito traballo debido á extensa flota de servidores, que inclúe bases de datos, sistemas de correo, clústeres de máquinas virtuais e recursos compartidos de ficheiros tanto en Windows como Linux/Unix. Os empregados que manteñen o sistema de copia de seguridade en funcionamento non permanecen inactivos.
En homenaxe ás vacacións, gustaríame desexarlles a todos os administradores nervios fortes, claridade nos movementos e espazo infinito para almacenar copias de seguridade.
Fonte: www.habr.com