Banco de dados do SQL Server em uma unidade de disco rígido externa

5

Devido a alguns problemas de segurança, Meu chefe me pediu para armazenar todos os dados confidenciais em armazenamentos externos / removíveis como pen drive ou HDD externo e isso inclui especialmente os arquivos MDF / NDF / LDF do SQL Server 2008 que estamos executando.

Eu tenho lido nestes últimos três dias sem sorte para encontrar uma solução. Existe alguma solução? Alguém já fez tal coisa?

    
por Achilles 02.08.2009 / 07:36

12 respostas

8

Bem, agora eu sei a resposta para a minha pergunta!

De acordo com o link , você pode usar o armazenamento SAN / NAS para armazenar os arquivos de seus bancos de dados usando um sinalizador TraceON. Algo como:

DBCC TraceOn(1807);
GO

este comando sinaliza o 1807 TranceOn para permitir que você use um UNC como "\ Server-name \ Path-to-Database-File.mdf" como o caminho para os arquivos de banco de dados. Agora você precisa criar uma pasta em seu HDD USB removível e usar "Compartilhamento e segurança" para conceder controle total sobre essa pasta para "Serviço de rede" ou qualquer usuário que seu SQL use para interagir com seu Windows. Lembre-se de remover todos e adicionar administradores também.

Agora você terminou; crie o banco de dados e divirta-se!

DBCC TraceOn (1807);
Go

Use master;
GO

CREATE DATABASE [test001] 
    ON  PRIMARY (
        NAME = N'test001', 
        FILENAME = N'\PC-Name-Where-Share-Is\TempDB\test001.mdf' , 
        SIZE = 2048KB , 
        FILEGROWTH = 1024KB
        )
    LOG ON ( 
        NAME = N'test001_log', 
        FILENAME = N'\PC-Name-Where-Share-Is\TempDB\test001_log.ldf' , 
        SIZE = 1024KB , 
        FILEGROWTH = 10%
    )
GO
    
por 05.08.2009 / 12:57
7

Mover-se como um banco de dados simples para uma unidade externa deve ser fácil:

  1. desanexe o banco de dados com exec sp_detach_db '<db_name>'
  2. copie os arquivos para o novo local na unidade externa
  3. reconecte o banco de dados com exec sp_attach_db '<db_name>', '<full_path_to_new_location_of_mdf>', '<full_path_to_ldf>'

(você também pode fazer isso através das ferramentas da GUI, anexar e desanexar são normalmente encontradas sob o título "todas as tarefas em menus relevantes de clique com o botão direito). Minha experiência é apenas com SQL7, 2000 e 2005, usando unidades internas em gabinetes USB, mas eu suponho que não é algo que terá mudado em 2008 (e deve funcionar com outros dispositivos USB de armazenamento em massa como flash sticks) .A unidade deve ser montada localmente - o SQL Server não permitirá que você conecte um banco de dados sobre armazenamento em rede.

Antes de desconectar a unidade, verifique se o banco de dados está desconectado ou se o SQL Server está desligado (ou a máquina está totalmente desligada, é claro). Se você liberar o disco para removível, desligando a máquina ou desligando o servidor SQL, a unidade precisa ser conectada antes do próximo início do servidor SQL.

Como outras pessoas apontaram, você terá um desempenho mais baixo na maioria dos casos. A maioria das unidades USB tem cerca de 25Mb / s mesmo que a unidade dentro do gabinete seja capaz de muito mais devido às limitações dos controladores USB2. Dito isto, se você tem muita coisa acontecendo em suas unidades internas (outro acesso ao DB e tal), você pode realmente achar que mover o banco de dados para um fuso separado, mesmo um conectado por uma interface mais lenta, pode melhorar a capacidade de resposta. não competindo pelo tempo no mesmo fuso com outro IO ativo e causando latência através de movimentos extras da cabeça). Isto supõe que você esteja usando um disco giratório SATA / PATA em um compartimento USB. Se você estiver usando um pendrive padrão USB baseado em flash, então o desempenho será muito menor ainda, especialmente para gravações - apesar da menor latência do armazenamento em estado sólido, o que ajudará em um grau, muitos bastões padrão não lerão muito mais rápido que 10MByte / seg e velocidades de gravação abaixo de 4Mbyte / seg estão longe de serem incomuns.

No ponto de segurança: ter os dados em mídia removível é apenas mais seguro se sua área de trabalho estiver totalmente segura (ninguém pode entrar / sair sem chaves e códigos, e você verificar quem você deixa entrar) e se quando você não estão presentes todos os drives externos são desconectados e armazenados em um cofre adequado. Caso contrário, a unidade removível é, na verdade, um pouco menos segura.

Todos os itens acima assumem que você está falando sobre o seu ambiente de desenvolvimento. Isso vai de "não particularmente recomendado" a "strongmente recomendado contra" se você estiver falando sobre algo próximo a um serviço ao vivo. E para desenvolvimento você não deve usar dados confidenciais de qualquer maneira. Você deve ter ou fabricado dados de teste ou não dados anônimos reais (todas as informações de identificação, como nomes, endereços e códigos de identificação suficientemente randomizados, se seus dados confidenciais forem informações pessoais).

Uma atualização para hardware mais moderno

Desde que o acima foi escrito, o USB3 tornou-se muito mais onipresente, o que altera um pouco o aspecto do desempenho. Um bom SSD de 2.5 "ou mSATA em um gabinete USB3 apropriado deve funcionar muito bem (não tão bem quanto uma unidade interna, é claro, e com um impacto de CPU, mas ainda assim). As outras considerações permanecem as mesmas.

    
por 02.08.2009 / 11:17
4

O "problema de segurança" que você tem é que não é difícil roubar fisicamente os dados? Porque estou tendo muitos problemas imaginando como uma unidade removível vai melhorar a segurança de dados.

    
por 02.08.2009 / 08:20
2

Qualquer dispositivo conectado via USB terá um desempenho tão ruim que tenho certeza de que seria insuportável. Você estaria melhor usando criptografia, até mesmo uma unidade criptografada

    
por 02.08.2009 / 07:45
1

eSATA é seu amigo - não use USB, Firewire ou qualquer solução NAS que não seja de 10 Gbps, um FC SAN seria ótimo, mas eles não são exatamente sinônimo de remoção - então eu escolheria um disco conectado a eSATA array, há muito sobre e eles não são muito caros.

    
por 05.08.2009 / 13:05
1

O USB 2.0 é dolorosamente lento, mas isso pode não ser um problema. Especialmente se o uso do seu banco de dados não for particularmente pesado e você tiver bastante RAM - idealmente, o SQL Server deve ser capaz para encaixar todo o banco de dados na RAM, no ponto em que a velocidade do disco não importará muito, uma vez que o SQL Server obtém a maior parte das páginas do banco de dados armazenadas na memória.

Se você precisar de mais desempenho de um dispositivo removível, tente o Firewire ou o eSATA. O FW800 fornecerá a você cerca de 80MB / s se a sua unidade for capaz disso. Até o FW400 é duas vezes mais rápido que o USB2 no mundo real. O eSATA é ainda mais rápido e você provavelmente não saturará essa interface sem o RAID.

Eu ficaria longe de flash drives. Eles têm baixa velocidade de gravação e não podem ser gravados muitas vezes, pois nem sempre eles têm controladores de nível de desgaste, como SSDs mais caros.

Os gabinetes de unidade removíveis de 3,5 "são uma opção? Seria bom se você pudesse usar um disco rígido interno normal montado em um trenó removível, como é comum na maioria dos servidores. absolutamente tem que ser fisicamente removido e bloqueado esta é a melhor solução, além de simplesmente ter o servidor em um local seguro, em primeiro lugar.

    
por 05.08.2009 / 13:51
0

Este é um desses requisitos que não faz absolutamente nenhum sentido e você não encontrará nenhuma recomendação para isso, porque ninguém em sã consciência o tentaria. Odeio ser tão pessimista e desafiador de suas necessidades, mas é assim.

Tendo dito tudo isso, sua melhor aposta, se ela se encaixar nas intenções do seu chefe, seria examinar um sistema iSCSI como o http://www.newegg.com/Product/Product. .aspx? Item = N82E16822107026 "> QNAP

    
por 02.08.2009 / 08:08
0

Não há motivo para não funcionar. A menos que você comece a puxar a unidade enquanto o SQL Server está em execução (você precisará desanexar manualmente o banco de dados para poder removê-lo com segurança).

O desempenho dependerá, um banco de dados pouco usado provavelmente sofrerá pouco. Um banco de dados muito usado precisa de vários fusos rápidos e terá um desempenho muito ruim em um único eixo - seja USB ou SAS.

Mas como um meio removível e mais portátil pode ser mais seguro? Você precisa entender o requisito subjacente para poder aconselhar seu chefe de maneira útil (se ele / ela está interessado em conselhos úteis é outra questão).

    
por 02.08.2009 / 10:40
0

Eu não usaria USB, mas usaria discos normais em gaiolas HotSwap.
Como você usaria uma única unidade USB do seu jeito, basta usar uma única unidade em uma gaiola hotswap e obterá a mesma segurança de uma unidade USB (de um ponto de falha). Faça um backup de seus arquivos em uma segunda unidade que também pode ser removida usando a gaiola HotSwap e você terá algo que proporcionará uma boa performance e & a segurança removível que o chefe exige. Além disso, eles não aparecem no Windows como armazenamento removível. Se você usar um bom controlador, pode até ser capaz de removê-los enquanto o sistema está rodando, como dito anteriormente, você deve separar os arquivos do banco de dados. Você poderia fazer isso como parte de um script em lote.

Normalmente, você pode obtê-los em gaiolas de unidades que também possuem chaves, o que aumentaria sua segurança enquanto está em execução, para que ninguém possa sair com elas.

Para acessá-lo de outro computador, digamos que você o tenha retirado por algum motivo e precise acessá-lo de outro computador (digamos, um laptop) e, em seguida, pegue uma das torradeiras ou cabos onde você pode soltar a unidade para isso e será legível por USB no outro computador.

    
por 02.08.2009 / 12:22
0

Colocando os dados em unidades USB removíveis para que você possa prender as unidades em condições noturnas ainda menos seguras para mim do que executar o banco de dados em um computador sob uma mesa.

Se os dados estiverem em uma unidade USB, alguém pode passar por ela, desconectar a unidade e colocá-la no bolso. Se os dados são armazenados em unidades internas no servidor, eles precisam levar o computador inteiro para obter os dados, o que é muito mais óbvio.

Se os dados no SQL Server forem realmente importantes, escolha um pequeno escritório (ou um repositório de armazenamento, desde que ele tenha uma boa AC) e marque isso como a sala do servidor. Coloque o SQL Server e outras máquinas executando processos do servidor nesta sala e bloqueie a porta. Certifique-se de que a equipe de limpeza saiba que não há nada lá para eles limparem, melhor ainda levar de volta a chave para aquela sala.

As únicas pessoas que devem ter acesso a essa sala (quem deve ter a chave da sala) são a pessoa ou pessoas que gerenciam os servidores. O gerente dessas pessoas provavelmente também desejará uma chave, mas na verdade não precisa de uma. Deve haver uma chave sobressalente em um envelope lacrado em uma gaveta trancada no escritório dos gerentes de RH, caso algo aconteça à equipe de TI.

Quanto à proteção de rede para impedir que as pessoas acessem os dados pela rede, isso deve ser feito por meio de práticas recomendadas normais (permissões mínimas, firewalls, etc.).

Quanto ao desempenho do SQL Server em uma unidade USB, o desempenho será horrível, pois o USB está muito lento, assim como pen drives e discos rígidos externos.

Em outras palavras, isso não deve ser feito.

    
por 02.08.2009 / 23:45
0

Se você usar o banco de dados do SQL Server em mídia removível, como HDD USB - o desempenho de seu banco de dados será limitado pela alternância de USB. Se o uso de seu banco de dados for limitado por 1-2 usuários periodicamente - tal solução pode ser utilizável de alguma forma, mas se mais usuários com (ou) acesso contínuo - eu acho que vai ser muito lento ou mesmo não utilizável ...

Eu uso o software Truecrypt (gratuito) / Bestcrypt (comercial) para criptografar mídia com arquivos de banco de dados do SQL Server (em RAID, não em HDD removível). Sim, adiciona alguma complexidade no procedimento de início do SQL Server (manual [re] start ou sp

por 03.08.2009 / 01:17
0

@ david-spillet sp_attachdb e sp_detach_db ficarão obsoletos depois do SQL 2008. Então você não pode usar esse comando daqui para frente

    
por 02.12.2009 / 02:04