Arquivo

Archive for the ‘Disaster e Recovery’ Category

(Enquete encerrada) Onde guardam seus backups?

Ola galera,
Essa enquete ficou ativa entre os dias 01/10/2016 à 04/01/2017, o objetivo era saber como as empresas estão armazenando seus dados, diante o cenário atual de segurança de dados!

Podemos observar que existe sim a preocupação no que se diz respeito a backup, apesar de vermos diversos casos no Estado do Ceará e no Brasil, de empresas que perdem todas (ou quase todas) as informações quando precisaram recuperar de um desastre, mais ai vem a questão: Será que estão sendo feitos testes nesses backups?

Pontos positivos:
62% dos participantes usam estratégias bem seguras em relação a backup (Servidor de Backup, Nuvem, Fita, Rede, Espelho ou Replicado);
– A questão de backup em Nuvem (18%), esta crescendo muito e atualmente é uma das opções mais acessíveis e rápidas de serem utilizadas;

Pontos negativos:
23% dos participantes informaram se seus backups são guardados em HD externo, não digo um ponto negativo, mas creio que devam ter uma segunda opção de backup, por ser tratar de uma mídia que pode dar problemas físicos com facilidade. Atenção galera!!!
14% informaram que fazem backup no próprio computador, isso é extremamente crítico se não feito como deve ser feito. Backup no computador é uma boa prática no que se diz respeito a volta rápida ao estado anterior, quando o problema não é na máquina ou no disco, mas essa estratégia obrigatoriamente deve ser seguida por alguma outra como por exemplo um backup em nuvem! Atenção galera!!!

Agradeço a todos pela atenção e espero ter ajudado com essa pesquisa, que no meu ponto de vista, levou a questão:

Seus backups são testados periodicamente?
Deixem seus comentários!

 

Anúncios

Existe problema sem solução?

Achei esse texto interessante e resolvi compartilhar… muito bom!

Um homem comprou um carro, que tinha um defeito curioso. Mandou uma carta à fábrica relatando seu problema: “Não os culpo se não responderem. Sei downloadque parece loucura. Toda noite, depois do jantar, pego o carro e vou tomar sorvete. Quando compro sorvete de Creme, o carro não funciona. Quando compro de outro sabor, liga na hora. Por que isto ocorre?”
A carta foi parar na mesa do presidente da empresa, que destacou seu melhor Engenheiro para desvendar o mistério. Incrédulo, o Engenheiro chegou à casa do homem na hora em que ele saía para comprar sorvete. Os dois foram juntos a sorveteria. Pediram de Creme. Voltaram ao carro. Ligaram… Nada.

No dia seguinte, repetiram o passeio. Pediram de Baunilha. O carro pegou. No terceiro dia, de Nozes. Tudo bem. No quarto, Cereja. O motor perfeito. No quinto, Creme, de novo. O motor não deu sinal de vida. Inacreditável. A única conclusão possível: O carro era alérgico a sorvete de Creme. O que fazer diante dessa constatação? Trocar o óleo por creme antialérgico?

O engenheiro não podia acreditar naquilo. Passou uma semana cruzando dados e comparando hipóteses. Um dia, olhando suas anotações, achou uma pista: O homem levava menos tempo para comprar sorvete de Creme. Como era um sabor bastante pedido, o latão com Creme ficava à mão do atendente. Para pegar os outros sabores, tinha de lavar a concha, enxugá-la, dar alguns passos para pegar o sorvete e mais outros para entregá-los ao cliente. Além disso, o de Creme custava R$ 1,00. Os outros sabores, R$ 1,20. Como o homem nunca tinha 20 centavos trocados, quando comprava de Chocolate ou de Morango tinha de esperar para receber e conferir o troco. Isso representava 01 minuto a mais.

Com isso, o mistério ganhou nova configuração. Não se tratava de o carro gostar ou não de sorvete de Creme. A questão agora era: Por que ele não funcionava quando se levava menos tempo? O engenheiro abriu o motor, conectou aparelhos a várias peças e descobriu que havia um relé com uma ventoinha defeituosa, que causava um problema de resfriamento. Touché! (ou Eureka, se preferirem). Quando o homem comprava sabores como Flocos ou Pistache, a peça tinha mais tempo para se resfriar. Quando pedia de Creme, o serviço era mais rápido, o relé ainda estava quente e não funcionava. Estava esclarecido o mistério. Era só não embarcar nas aparências, estudar o problema com cuidado e encontrar o caminho certo.

Moral da história: Se você, caro amigo (a), se encontra desesperado, sem encontrar uma solução para seu problema, tenha calma. Coloque a cabeça para funcionar e analise os fatos. Por mais complicado que seja, não há problema sem solução.

Fonte

Será que você precisa de Alta Disponibilidade nos seus ambientes?

Todos os direitos reservados a Fabio Cotrim (Especialista em Banco de Dados MS SQL Server)
Matéria original

Introdução

Nesta apresentação, pretendo levantar algumas questões para ajudar aos DBAs avaliarem as reais necessidades de implementar a alta disponibilidade nos ambientes que administram.

Como toda nova funcionalidade de uma ferramenta, vários profissionais, técnicos ou gerenciais, querem implantá-las, mais por ser moda do que por ter real necessidade, e não está sendo diferente com os recursos de alta-disponibilidade criados para os ambientes de bancos de dados, mas, nem sempre, eles serão úteis para a maioria dos ambientes, pois poderão ser complicadores para a administração e, em alguns casos, para a recuperação após um desastre.

Aconselho que analisem a situação de uma forma menos emocional, deixando um pouco de lado a vontade de ser um vanguardista.

Quando questionados, a maioria dos usuários dos ambientes, respondem que seus ambientes são totalmente indispensáveis para o funcionamento da empresa, o que, em muitos casos não é verdade.

Um exemplo simples, é desabilitar a calculadora de troco do caixa de uma padaria; o funcionário  vai afirmar que não consegue executar as suas tarefas, mesmo que ele tenha uma caneta e papel à disposição; esta ação seria um dificultador, mas não causaria um impedimento à realização das tarefas. Ok, você vai dizer que fui cruelmente exagerado neste exemplo, mas pode ficar tranquilo que não sou tão maléfico assim, foi só uma forma de exemplificar a situação.

Em um outro exemplo, este sendo de uma forma que a indisponibilidade de um recurso causaria a parada nas operações e, consequentemente, eliminaria as receitas de uma empresa, seria retirar todas as ferramentas de um mecânico; neste caso, ele não poderia realizar nenhum trabalho até que as ferramentas fossem disponibilizadas novamente.

Em TI, o que é Alta Disponibilidade?

São ambientes que têm a capacidade de tolerar falhas, de tal forma que, o processamento continue com pouca ou nenhuma interrupção, de forma transparente ao usuário, permitindo que a equipe de infraestrutura tenha tempo, e consequente serenidade, para realizar os reparos necessários.

Para quem a Alta Disponibilidade é mais útil?

Quem realmente precisa de Alta Disponibilidade, são os serviços que nunca podem ficar parados, como os serviços essenciais, ou empresas que oferecem seus produtos e serviços aos clientes em período 24×7, tais como:

  • Hospitais;
  • Polícia;
  • Bombeiros;
  • Energia Elétrica;
  • Aeroportos;
  • Serviços de Água e Esgoto;
  • Companhia de Engenharia de Trânsito;
  • Instituições Financeiras;
  • Indústrias 24×7;
  • E-commerce, etc.

Leia mais…

Hackers invadem computadores e celulares e sequestram dados

A importância da Tecnologia da Informação!

Ola galera!
Sempre costumo comentar sobre a importância da Tecnologia da Informação em uma empresa, seja ela pequena ou grande!
Mas vemos que a grande maioria das empresas não dão a devida importância para esse tema, devido a pensarem que a TI é somente custos!

Nos últimos dias, estamos vendo a questão de sequestro de dados e isso pode ser que abra (ou não) os olhos dessas empresas e que essas possam dar a devida importância à tecnologia da informação, antes de acontecer o que aconteceu por exemplo com a prefeitura de Pratânia (SP).

Esse situação exposta no vídeo abaixo, poderia ter sido evitada com o uso de um sistema de segurança da informação mais efetivo!
Um sistema de backup efetivo também poderia ter evitado todo esse transtorno, pois mesmo com a invasão, os dados poderiam ser recuperados em um tempo bem curto!

Pelo que andei pesquisando sobre essa invasão, a prefeitura acabou desistindo de recuperar o sistema e estão adquirindo um novo sistema, ou seja, investindo em um novo sistema e provavelmente agora vão investir em segurança da informação! E isso poderia ter sido feito antes com um custo muito menor!

Fica a dica…
Cuide bem do seu bem mais precioso, seus dados! Pois eles são a base de sua empresa!

Vejam o vídeo abaixo!

Links
Invasão de hackers paralisa a prefeitura de uma cidade em SP
Prefeitura desiste de recuperar sistema invadido por hackers
Hackers invadem sistema interno da Prefeitura de Guaranésia, MG
Mais uma Prefeitura foi vítima de Hackers através de um Malware – Castanheira (MT)
Hackers invadem sistema de prefeitura em MT e serviços são suspensos – Sorriso (MT)
Backup no SQL Server

Sabem o que é BYOD?

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Acordo de Nível de Serviço (SLA)

Um passo importantíssimo para entregar o valor esperado pelos clientes com os serviços de TI é garantir que exista um acordo de nível de serviço, planejado por todas as áreas de TI bem como com o cliente final. Logicamente não basta existir um SLA (Service Level Agreements), ele deve ser cumprido, mas o fato de existir algum SLA já é o primeiro passo, por que significa que o mesmo foi discutido dentro da área de TI bem como com o cliente.

O SLA é útil para garantir que os serviços entregues atendem às expectativas de negócios, as metas de desempenho e os custos necessários para a entrega de um determinado serviço de TIC a um conjunto de clientes. Um SLA eficaz reflete a comunicação entre os clientes e usuários (os consumidores do serviço) e deverá traduzir-se na tabela de indicadores. Os objetivos de nível de serviço que são identificados, em seguida, serão usados para desenvolver e personalizar o scorecard de aderência para o serviço.

O SLA deve ser balanceado entre ser relevante e factível. Em geral, a disponibilidade desejada por todos é de 100%, mas isso, infelizmente, é irreal. O SLA deve conter um objetivo relevante a ponto de atingir o nível de serviço realmente necessário e exigido pelo negócio, mas também deve ser possível de ser entregue, não pode conter premissas ou promessas irreais.

Um SLA deve possuir a descrição e definição, em linguagem clara para o cliente, de todos os pontos importantes sobre o serviço de TIC. Por exemplo, descrição do serviço, seus requerimentos, necessidades de dados de entrada, saídas esperadas, horários de funcionamento do serviço, tempos de atendimento ao usuário em caso de problema, disponibilidade total esperada, tempo de retorno em caso de indisponibilidade, etc.

Cálculo de Disponibilidade

Um dos pontos mais comuns de ser descrito em um SLA é a disponibilidade esperada do serviço. Um indicador comum usado para medir a disponibilidade é o percentual de tempo que um serviço foi capaz de servir aos seus clientes e usuários.

  • Percentagem de disponibilidade = Tempo Total em Serviço / Tempo Total Esperado em Serviço

No caso de um serviço que é esperado que funcione 24 x 7, o tempo total esperado, no ano, é de 24 horas x 365 dias = 8760 horas.

Em geral, a disponibilidade desejada por todos é 100%, mas isso, infelizmente, é irreal. Num caso mais realista, a disponibilidade nos SLAs é medida em “noves”, ou seja, quantos “noves” no percentual são esperados. Um serviço que é esperado “3 noves” deve ter disponibilidade de 99,9%.

A tabela abaixo mostra os cálculos de disponibilidade em relação a um serviço 24×7, com base anual.

% Disponibilidade Horas Totais no Ano (24×7) Tempo máximo de indisponibilidade Horas Totais no Ano (8×5) Tempo máximo de indisponibilidade
90% 8760 horas 876 horas (36,5 dias) 2086 horas 208.6 horas (26 dias)
95% 8760 horas 438 horas (18,3 dias) 2086 horas 104 horas (13 dias)
99% (2 noves) 8760 horas 87 horas (3,6 dias) 2086 horas 20,86 horas (2,6 dias)
99,9% (3 noves) 8760 horas 8,76 horas 2086 horas 2 horas
99,99% (4 noves) 8760 horas 52,56 minutos 2086 horas 12,5 minutos
99,999% (5 noves) 8760 horas 5,3 minutos 2086 horas 1,25 minutos

Como pode ser reparado na tabela de tempos de indisponibilidade, o tempo máximo aceitável de indisponibilidade é alterado com a alteração do tempo total esperado de serviço (janela de funcionamento do serviço). No caso de um serviço em horário comercial (8×5), uma queda do sistema durante a madrugada, com o serviço voltando a funcionar antes ainda do horário comercial não afeta o cálculo de disponibilidade para efeitos do SLA, por que o serviço não tinha a obrigação de funcionar fora da sua janela estipulada.

O que deve ser considerado para confecção de um SLA?

A Microsoft recomenda considerar os seguintes pontos quando da criação e manutenção de SLAs e medições de disponibilidade:

  • Necessidades reais de negócio – Os custos de alcançar maior disponibilidade podem não valer a pena considerando os benefícios reais necessários. Analise a real disponibilidade de serviço de TIC que sua empresa realmente precisa antes de definir metas. Ter sempre meta de 24×7 com 99,999% de disponibilidade pode ser desejável para todos os serviços, mas obriga um enorme investimento em pessoas, processos e tecnologia a fim de atingir esse nível e poucos serviços realmente precisam disso.
  • Correta granularidade – Um sistema de TI, seja qual for, tem múltiplas medições e monitorações de disponibilidade, e não simplesmente funcionando e parado. Partes distintas podem estar funcionando enquanto outras podem ter algum problema de disponibilidade. Uma regra simples, clara e justa deve ser alcançada para que o cálculo não seja mais custoso que a informação resultante deste.
  • Responsabilidade e Cobrança – uma pessoa ou time deve ser responsável por cada medição, e deve ser garantido poder de decisão necessário para que seja feito o que é necessário para controlar o serviço e respeitar os SLAs.
  • Riscos Ordinários e Extraordinários – Falha de disco ou memória, bem como rede e falta de energia são riscos ordinários, previsíveis, que são parte do cotidiano. Você sabe que os enfrentará mais cedo ou mais tarde e deve se planejar para quando isso ocorrer. A maior probabilidade de indisponibilidade pode ser tratada analisando e previnindo riscos ordinários.
    O tipo de planejamento a ser feito para riscos extraordinários é bem diferente e deve inclusive levar em conta risco de perda de pessoal e instalações. São eventos mais raros e especiais, mas que devem ser avaliados se vale a pena prevení-los ou apenas conhecê-los e preparar reação em caso de ocorrência. Isso vai depender do custo da prevenção e também da quantidade e importância dos recursos envolvidos pelo risco.
  • Escopo e tolerâncias – métricas rígidas e absolutas podem trazer mais malefícios do que benefícios. Atritos entre áreas, avaliações e auditorias no cálculo do SLA e outros fatores podem ser resultados de intolerâncias. Em geral, recomenda-se trabalhar com médias e desvio padrão para cálculos de indicadores de SLA.
  • Mensurabilidade – cada item do SLA deve ter um indicador e meta determinada. O SLA deve ser oficializado em cima de valores trangíveis e objetivos, nunca sobre avaliações pessoais e subjetividade. Termos como “melhor”, “mais disponível”, “total”, etc. devem ser evitados, dando-se preferência para “10% de melhoria a cada ano”, ou ainda, “99% de disponibilidade claculada sobre a fórumula XXX =YYY / ZZZ”.
  • Margens de Erro – um outro aspecto da capacidade de medir algo é a margem de erro de medição. Por exemplo, a Microsoft possui dezenas de Active Directory Domain Controllers e Exchange Servers espalhados pelo mundo em diversos datacenters. Sincronização de horário entre todos os serviodres pode levar um certo tempo e ainda assim acontecer com pequenas diferenças de horário. Uma mensagem de ping pode ter o seu horário de chegada, visto por um servidor, milisegundos antes do seu horário de saída. Sabemos que isso é impossível, logo deve-se ao fato de sincronização e outros detalhes inerentes a distribuição e às margens de erro de medição. As objetivos de nível de serviço não devem ser tão pequenos e precisos que sejam da mesma ordem de grandeza que a margem de erro de medição.

Reunião de Revisão de Nível de Serviço

Conduzir uma reunião regular de Revisão de Nível de Serviço é uma forma importante de entender o estado atual do serviço. A revisão frequente dos dados atingidos mantém o foco de trabalho nos mais importantes indicadores de negócio, bem como pode alertar com boa antecedência para eventuais desvios aos objetivos dos SLAs.

Após a documentação e formalização do serviço do SAJ com mapa de serviço, SLAs, OLAs, e a tecnologia totalmente revisada e corretamente configurada, a manutenção dos níveis de serviço requerem criação de:

  • Procedimentos operacionais para todos os componentes do serviço, a fim de garantir que todas as engrenagens estão funcionando corretamente, e de suporte, a fim de garantir que o atendimento ao usuário está sendo feito conforme o acordado no SLA;
  • Disciplina e comprometimento do time a fim de colocarem em prática uma reunião de Revisão de Nível de Serviço com frequência mínima quinzenal.

Fonte: Ronaldo Smith Jr

Perda de dados custa às empresas brasileiras US$ 26 bilhões em 12 meses

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Companhias tiveram 17 horas de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos

A perda de dados e tempo de inatividade custou aproximadamente US$ 26 bilhões às empresas brasileiras no último ano. Mundialmente, o montante foi de US$ 1,7 trilhão. É o que apontou um estudo encomendado pela EMC, que indica que 62% dos profissionais de TI do Brasil não confiam integralmente em sua capacidade de recuperar informações após um incidente.

Além disso, 61% das organizações não têm plano de recuperação de desastres para cargas de trabalho emergentes; e apenas 4% têm planos para big data, nuvem híbrida e dispositivos móveis. De acordo com o levantamento, “nenhuma das organizações do Brasil são ‘Líderes’ em proteção de dados; 9% são ‘Adotantes’; 91% estão desatualizadas”, informa a fabricante.

Apesar de o número de incidentes estar em queda, o volume de dados perdidos por incidente cresce exponencialmente. De acordo com o estudo, 59% das empresas pesquisadas passaram por perda de dados ou tempo de inatividade nos últimos 12 meses.

Na média, as empresas tiveram 17 horas (mais de dois dias de trabalho) de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos.

Segundo a pesquisa, empresas com três ou mais fornecedores perderam quase cinco vezes mais dados em comparação com as que têm estratégia de um só fornecedor.

“As empresas com três fornecedores também tenderam a gastar, em média, US$ 15 milhões a mais na infraestrutura de proteção de dados, em comparação com as que têm apenas um”, informa o relatório.

O EMC Global Data Protection Index, realizado pela Vanson Bourne, pesquisou 3,3 mil responsáveis por decisões de TI de médias a grandes empresas em 24 países entre agosto e setembro de 2014.

Fonte: Site Computerworld

%d blogueiros gostam disto: