A recuperação de SSD empresarial exige olhar além do dispositivo isolado. NVMe U.2/U.3, EDSFF, SAS, SATA, namespaces, dual-port, PLP, RAID, controladora, storage e virtualização podem fazer parte do mesmo incidente. Em ambiente de produção, registrar o estado antes de alterar qualquer componente é parte da preservação.
O que é recuperação de SSD empresarial?
Um SSD empresarial pode ser detectado normalmente em um servidor e ainda apresentar media errors, latência crescente, read-only ou alertas de saúde. Também pode desaparecer da controladora, ser marcado como Failed, deixar um RAID degradado ou tornar um datastore inacessível. O diagnóstico correto precisa separar falha da unidade, falha de backplane, falha de caminho, firmware, namespace e problema do próprio array.
Guia completo de recuperação de SSD empresarial
O que muda em um SSD empresarial?
SSDs empresariais não são apenas SSDs de consumidor com maior capacidade. Fabricantes de data center adicionam recursos orientados a disponibilidade, endurance, telemetria, consistência de latência, proteção contra perda de energia, segurança e integração com servidores e storages.
Power Loss Protection
Produtos de data center podem incorporar PLP para proteger dados em trânsito e metadados durante perda de energia. Isso reduz riscos, mas não torna o SSD imune a falhas.
Endurance e DWPD
Linhas enterprise são classificadas por workloads de leitura, mixed-use e escrita. DWPD e TBW ajudam a dimensionar desgaste, mas não predizem sozinhos a recuperação.
Data Path Protection
Proteções end-to-end e ECC procuram detectar corrupção em diferentes partes do caminho de dados, do host à NAND.
Dual-port e multipath
Alguns SSDs SAS e NVMe enterprise oferecem dois caminhos para alta disponibilidade. Um caminho funcional não significa que a unidade esteja saudável.
Telemetria
SMART, health logs, media errors, unsafe shutdowns, error logs e dados de plataforma podem ajudar a reconstruir o histórico do incidente.
Segurança
TCG Opal, encryption at rest, secure boot, sanitize e outras funções alteram o cenário quando firmware ou controladora falham.
Como exemplos atuais, fabricantes como Samsung, Micron, KIOXIA, Solidigm e Seagate oferecem linhas data center com PLP, proteção de dados, NVMe, SAS ou SATA e diferentes níveis de endurance. A arquitetura exata precisa ser identificada pelo modelo, não apenas pela marca.
Principais sintomas de SSD empresarial em falha
Não aparece no servidor
O SSD some da UEFI, BMC, controladora ou sistema. A causa pode estar na unidade, backplane, alimentação, protocolo ou firmware.
Predictive Failure
Alertas de saúde indicam risco crescente. O objetivo deve ser validar backup e preservar dados, não manter produção até a falha total.
RAID Degraded ou Failed
A falha pode estar em um membro, em múltiplos SSDs, nos metadados do array ou na controladora. Rebuild automático pode agravar.
Read-only
Algumas unidades entram em proteção contra escrita diante de condições críticas. Se ainda lê, pode existir uma janela de aquisição.
Latência e timeouts
Media errors, NAND degradada, firmware ou retries internos podem causar filas, timeouts e queda de desempenho antes da indisponibilidade.
Datastore inacessível
O SSD pode estar fisicamente presente, mas VMFS, ReFS, ZFS, LVM ou outra camada lógica deixou de montar.
Desconexões intermitentes
Problemas em backplane, dual-port, cabo, HBA, alimentação ou controladora SSD podem parecer uma falha lógica do volume.
Media errors crescentes
Logs NVMe ou ferramentas de servidor podem indicar aumento de erros de mídia, desgaste ou blocos indisponíveis.
Temperatura ou throttling
Problemas térmicos podem reduzir desempenho. É preciso separar throttling normal de instabilidade real da mídia.
NVMe U.2/U.3, SAS, SATA, M.2, E1.S e E3.S: o que realmente muda?
| Interface / formato | Onde aparece | Ponto de diagnóstico | Risco em recuperação |
|---|---|---|---|
| NVMe U.2 | Servidores e storages PCIe | NVMe, namespaces, health logs, backplane e PCIe | Confundir falha do slot ou caminho com falha da unidade |
| NVMe U.3 | Plataformas data center modernas | Backplane compatível, NVMe e gerenciamento | Troca ou movimentação sem registrar posição e protocolo |
| NVMe M.2 | Boot, edge, servidores compactos | M.2 é formato; o protocolo pode ser NVMe | Adaptadores incorretos e aquecimento |
| EDSFF E1.S / E3.S | Data centers de alta densidade | PCIe/NVMe, térmica, hot-swap e gerenciamento | Formato novo exige adaptação e suporte adequados |
| SAS | Storages e servidores de alta disponibilidade | Protocolo SAS/SCSI, dual-port, HBA e multipath | Ferramenta SATA não se comunica automaticamente com SAS |
| SATA enterprise | Servidores, boot e storage mainstream | ATA/SATA, PLP, firmware e endurance | Tratar como SSD de consumidor sem considerar firmware enterprise |
10 passos quando um SSD empresarial falha em produção
O que não fazer em SSD empresarial
Rebuild sem diagnóstico
Rebuild gera intensa leitura e escrita. Se houver outro membro instável, o array pode perder a redundância restante durante o processo.
Importar configuração Foreign às cegas
Antes de aceitar configurações encontradas pela controladora, confirme se correspondem ao estado correto do array.
Atualizar firmware do drive
Em dados críticos, firmware update pode alterar o estado de uma unidade que ainda possui uma janela de leitura.
Sanitize ou Secure Erase
Ferramentas de gerenciamento enterprise incluem funções de sanitização. Confirme cada comando antes de executar.
Misturar slots
Em RAID, Storage Spaces, mdraid e outras topologias, posição e identidade dos membros ajudam a reconstruir o conjunto.
Testar individualmente sem contexto
Um SSD de array pode parecer legível sozinho e ainda assim conter apenas fragmentos de stripes, paridade ou objetos distribuídos.
Como funciona a recuperação de SSD empresarial na SECURITY
O processo varia conforme o dispositivo e o ambiente. Um NVMe U.2 em servidor pode exigir um caminho diferente de um SAS dual-port em storage ou de um SATA de boot.
Onde entram PC-3000 e Data Extractor?
A ACE Lab informa que o PC-3000 SSD Extended suporta uma ampla variedade de formatos e controladores, incluindo SATA, M.2 SATA, M.2 PCIe NVMe/AHCI, PCIe x16 e outras arquiteturas. O suporte é específico por controlador e firmware e evolui com as versões do software. Em recuperação, ferramenta profissional não equivale a suporte universal.
Power Loss Protection ajuda, mas não torna SSD empresarial infalível
PLP é um diferencial real de muitas linhas data center. Fabricantes como Samsung, Micron, KIOXIA e Solidigm publicam produtos com recursos de proteção contra perda de energia e proteção end-to-end. O objetivo é reduzir o risco de dados em trânsito e metadados ficarem inconsistentes quando a alimentação some.
Isso não impede falhas de NAND, desgaste, firmware, controlador, backplane, sobretemperatura, problemas de projeto ou eventos fora das condições previstas. Por isso, "tem PLP" não deve ser interpretado como "não pode corromper".
DWPD e workload
Drive Writes Per Day mede a quantidade de gravação diária que a unidade foi projetada para suportar dentro de determinadas condições e período de garantia. Produtos read-intensive, mixed-use e write-intensive podem ter endurance muito diferente. A Solidigm, por exemplo, publica linhas com perfis extremos de escrita, enquanto KIOXIA diferencia CM7-R e CM7-V por workload.
Na recuperação, esse dado ajuda a interpretar histórico de uso, mas o que importa é o estado atual do SSD e a possibilidade de leitura estável.
Namespaces, U.2, U.3, EDSFF e dual-port
A NVM Express define NVMe como padrão para comunicação com memória não volátil em formatos como U.2, M.2, AIC e EDSFF. Um namespace é um volume lógico de blocos associado a capacidade de memória não volátil. Um controlador pode expor um ou vários namespaces.
Namespace não é partição
Dentro do namespace podem existir GPT, MBR, LVM, VMFS, NTFS, ReFS ou outras estruturas. Se o namespace deixa de ser apresentado, o sistema pode não enxergar as partições, mas isso não significa que uma partição seja o próprio namespace.
U.2 e U.3
U.2 e U.3 aparecem em servidores e storages de 2,5 polegadas. O diagnóstico deve considerar backplane e compatibilidade da plataforma. Um SSD em um slot fisicamente semelhante pode usar comunicação diferente.
E1.S e E3.S
EDSFF foi criado para data centers com foco em densidade, térmica, sinal e manutenção. Samsung PM1743, Micron 7400 e KIOXIA CM7 são exemplos de famílias que existem em formatos EDSFF ou data center modernos.
Dual-port
Produtos enterprise podem oferecer dois caminhos PCIe ou SAS para alta disponibilidade. Uma falha percebida em um caminho precisa ser diferenciada de falha do SSD inteiro.
SSD empresarial em RAID: recuperar o drive não basta
Em RAID, os dados podem estar distribuídos por vários membros. Um SSD recuperado individualmente pode conter apenas partes de arquivos, stripes ou paridade. A reconstrução precisa considerar todos os membros relevantes e a geometria do array.
| Camada | O que registrar | Risco de intervenção |
|---|---|---|
| Drive | Serial, slot, interface, health e capacidade | Troca de posição ou firmware update |
| Controladora RAID | Modelo, firmware, estado do virtual disk, cache | Importar configuração ou iniciar rebuild indevido |
| Geometria | RAID level, ordem, stripe size, offset e paridade | Reconstrução virtual incorreta |
| Storage pool | LUN, pool, thin provisioning, snapshots | Recriação de volume e UNMAP |
| Virtualização | VMFS, vSAN, CSV/ReFS, LVM, ZFS | Montagem com escrita ou repair |
| Aplicação | Banco de dados, ERP, arquivos, VMs | Validar somente nomes sem verificar integridade |
Dell PERC, HPE Smart Array e Broadcom MegaRAID
Controladoras diferentes usam formatos próprios de metadados e políticas de cache. O princípio seguro é registrar o estado atual antes de importar, inicializar ou reconstruir qualquer configuração.
RAID por software
Windows Storage Spaces, Linux mdraid, ZFS, VMware vSAN e outras soluções adicionam metadados e objetos próprios. Em alguns ambientes, "RAID" é apenas uma parte de uma camada distribuída maior.
Quando a falha do SSD derruba máquinas virtuais
Em ambientes virtualizados, a recuperação atravessa várias camadas. Primeiro vem o SSD ou o array. Depois vêm datastore, volume, thin provisioning e discos virtuais. Só então é possível validar sistema operacional e aplicação dentro da VM.
VMware ESXi
VMFS, vSAN, VMDK, snapshots e objetos de storage precisam ser analisados após estabilizar o hardware.
Hyper-V
CSV, NTFS ou ReFS, VHDX e checkpoints podem exigir reconstrução em múltiplas etapas.
Proxmox
LVM-thin, ZFS, Ceph, QCOW2 e raw podem estar sobre SSDs locais ou storage distribuído.
Em banco de dados, não basta recuperar o arquivo. MDF, LDF, PostgreSQL, MySQL, Oracle e outros formatos precisam ser validados estruturalmente quando fazem parte da entrega.
TCG Opal, SED e criptografia no SSD empresarial
SSDs empresariais podem usar criptografia interna transparente. Em Self-Encrypting Drives, a controladora participa diretamente da criptografia e descriptografia dos dados. Isso muda a recuperação porque a NAND isolada pode conter conteúdo cifrado.
TCG Opal não deve ser confundido com BitLocker. BitLocker é uma camada do sistema operacional e pode coexistir com um SSD que também possui recursos de criptografia próprios. O diagnóstico deve registrar credenciais, políticas e estado original da unidade.
Modelos e famílias de SSD empresarial encontrados em servidores e data centers
Esta lista serve como cobertura semântica e referência de arquitetura. Não significa que todos os modelos possuem o mesmo suporte de recuperação. A viabilidade deve ser confirmada individualmente.
Samsung
PM893 e outras linhas SATA data center, PM9A3 em U.2, M.2 e E1.S, PM1743 em PCIe 5.0 e E3.S/2,5", além de PM1653 SAS dual-port.
Micron
5400 SATA data center, 7400 e 7450 NVMe em U.3, M.2 e E1.S, além de linhas atuais U.3 com PLP e proteção end-to-end.
KIOXIA
CM7-R e CM7-V NVMe, formatos 2,5" e E3.S, workloads read-intensive e mixed-use, além de linhas enterprise dual-port.
Intel / Solidigm
D3 SATA e famílias D5/D7 de data center, com diferentes perfis de endurance, PLP e NVMe.
Seagate Nytro
Linhas enterprise e data center em diferentes gerações e interfaces, incluindo SSDs NVMe para workloads corporativos.
WD / SanDisk / Ultrastar
Famílias data center e SAS/NVMe históricas e atuais podem aparecer em storages OEM e servidores de diferentes fabricantes.
Cenários técnicos de recuperação de SSD empresarial
NVMe U.2 marcado como Failed em RAID de servidor
Contexto: um SSD deixa o array e o servidor oferece rebuild para uma unidade substituta.
Ação de risco: iniciar rebuild sem avaliar os demais membros.
Estratégia: registrar slot, serial, estado da controladora, logs NVMe e preservar todos os SSDs relevantes. O drive problemático é avaliado individualmente antes de decidir reconstrução.
Objetivo: obter imagens estáveis dos membros e reconstruir o array fora do ambiente de produção quando necessário.
SATA enterprise entra em read-only com banco de dados ativo
Contexto: servidor continua online, mas gravações falham e o SSD aceita leitura.
Ação de risco: tentar remover o read-only, atualizar firmware ou continuar produção.
Estratégia: aproveitar a janela de leitura para aquisição controlada, preservando arquivo de dados, logs e metadados antes de qualquer manutenção.
SSD SAS dual-port desaparece de um caminho do storage
Contexto: multipath mantém o serviço por um caminho enquanto o outro apresenta erro.
Ação de risco: concluir que o SSD está saudável porque o volume ainda monta.
Estratégia: diferenciar falha de porta, backplane, HBA e unidade; registrar logs de ambos os caminhos e planejar migração ou aquisição antes da degradação avançar.
Datastore VMFS sobre RAID de SSDs fica inacessível
Contexto: VMs param após falha de múltiplos membros e tentativas de rebuild.
Ação de risco: montar, reparar ou recriar datastore antes de preservar os membros.
Estratégia: adquirir SSDs, reconstruir a geometria do array, localizar VMFS e então validar VMDKs e aplicações.
Perguntas frequentes sobre recuperação de SSD empresarial
SSD empresarial não reconhecido pelo servidor tem recuperação?
Pode ter. O desaparecimento do SSD do BIOS, UEFI, BMC, controladora RAID ou sistema operacional pode envolver alimentação, backplane, interface, firmware, controladora, namespace, mídia NAND ou falha do próprio array. A viabilidade depende do modelo, do protocolo e do estado do dispositivo.
Qual a diferença entre SSD empresarial e SSD comum na recuperação?
SSDs empresariais costumam ser projetados para cargas contínuas, maior endurance, telemetria, proteção de dados, recursos de power loss protection, segurança e formatos específicos de data center. Isso muda o contexto de diagnóstico, especialmente em RAID, servidores, dual-port NVMe, SAS e storages.
U.2 e U.3 são a mesma coisa?
Não. Ambos podem aparecer em SSDs NVMe de 2,5 polegadas, mas U.3 foi projetado para maior flexibilidade de backplane e interoperabilidade com diferentes protocolos em plataformas compatíveis. O diagnóstico deve confirmar o drive, o backplane e o protocolo efetivamente usado.
Namespace NVMe substitui partição GPT ou MBR?
Não. Um namespace NVMe é um espaço de armazenamento lógico apresentado pelo controlador, organizado em LBAs. Partições GPT ou MBR e sistemas de arquivos podem existir dentro de um namespace. Confundir essas camadas pode levar a procedimentos incorretos.
SSD SAS empresarial exige ferramentas diferentes de SATA?
Sim. SAS usa protocolo SCSI sobre Serial Attached SCSI e pode incluir dual-port e multipath. Um equipamento que trabalha apenas com SATA não se comunica automaticamente com SAS. O diagnóstico deve ser feito com suporte ao protocolo correto.
Posso dar rebuild no RAID quando um SSD empresarial falha?
Não é uma decisão segura sem avaliar todos os membros. Rebuild escreve grandes volumes no array e pode expor outros SSDs degradados, alterar metadados ou consolidar uma geometria incorreta. Quando os dados são críticos, registre o estado e preserve os membros antes de reconstruir.
O que significa Predictive Failure em um SSD empresarial?
É um alerta de saúde ou confiabilidade gerado pela unidade, controladora, firmware ou plataforma. Não significa necessariamente que todos os dados já foram perdidos. Deve ser tratado como sinal para preservar dados, validar backup e reduzir operações desnecessárias.
Power Loss Protection impede qualquer perda de dados?
Não. PLP é projetado para reduzir risco de perda de dados em trânsito e inconsistências durante quedas de energia, mas não torna o SSD imune a falhas de NAND, controladora, firmware, backplane, desgaste, bugs ou outros eventos.
SSD empresarial em read-only pode ser recuperado?
Pode ser um bom momento para aquisição, pois ainda existe acesso de leitura. Porém, read-only também pode indicar condição crítica ou proteção. O ideal é preservar os dados antes de tentar alterar o estado da unidade.
TCG Opal ou SED muda a recuperação?
Sim. Self-Encrypting Drives podem criptografar dados internamente no controlador. A recuperação precisa preservar a cadeia de acesso à criptografia. Ler NAND ou trocar componentes não garante dados utilizáveis se as chaves e o controlador original forem necessários.
Quais interfaces aparecem em SSDs empresariais?
SATA, SAS e NVMe sobre PCIe são comuns. Em NVMe existem formatos M.2, U.2, U.3, placas AIC e EDSFF como E1.S e E3.S. A interface e o formato físico não devem ser confundidos.
SSD empresarial pode falhar por desgaste mesmo sendo feito para servidor?
Sim. Endurance maior não significa vida infinita. DWPD, TBW, write amplification, temperatura, carga aleatória, over-provisioning, firmware e qualidade da NAND influenciam o desgaste ao longo do tempo.
É possível recuperar VMs de um SSD empresarial com falha?
Pode ser possível quando os dados físicos e as camadas lógicas ainda podem ser adquiridos. Depois da estabilização do SSD ou do RAID, pode ser necessário reconstruir VMFS, ReFS, LVM, ZFS ou outras estruturas antes de validar VMDK, VHDX, QCOW2 e máquinas virtuais.
A SECURITY atende SSD empresarial de todo o Brasil?
Sim. A SECURITY atende clientes de diferentes regiões do Brasil e orienta envio seguro. Para Barueri, este artigo prioriza Alphaville, além de pontos de atendimento em São Paulo e Campinas.
Atendimento para SSD empresarial, servidor e storage
A SECURITY atende clientes de diferentes regiões do Brasil e orienta envio seguro de SSDs, arrays e componentes de storage. Em Barueri, este artigo prioriza Alphaville.
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 em recuperação de dados, incluindo SSD, RAID, NAS, servidores, PC-3000, Data Extractor e projetos de alta complexidade.
SSD empresarial por dentro: namespaces, PLP, NAND, firmware, RAID e virtualização
Esta seção aprofunda as camadas que mais influenciam a recuperação de SSDs em servidores e storages. O objetivo é mostrar por que uma falha enterprise raramente deve ser analisada apenas como "um SSD que parou".
1. NAND, FTL e mapa lógico-físico
Assim como em SSDs client, o host acessa LBAs e a controladora traduz esses endereços para páginas e blocos NAND. Wear leveling, garbage collection, over-provisioning e remapeamentos alteram continuamente a posição física. Quando firmware ou estruturas internas falham, os dados podem existir sem acesso lógico normal.
2. Por que endurance maior não elimina falha
SSDs empresariais são especificados para workloads definidos. Alguns modelos suportam uma fração de DWPD; outros são projetados para dezenas de gravações completas por dia. A endurance representa um envelope de projeto, não uma garantia de que toda unidade chegará ao limite sem falha de firmware, controladora ou NAND.
3. PLP protege dados em trânsito
Power Loss Protection usa energia residual para concluir operações críticas ou levar metadados a um estado consistente. Produtos enterprise atuais de Samsung, Micron, KIOXIA e Solidigm documentam PLP ou tecnologias equivalentes. Porém, PLP não corrige NAND degradada nem evita todos os bugs de firmware.
4. Data Path Protection e ECC
Proteções end-to-end procuram detectar erros à medida que os dados atravessam interface, buffer, controladora e NAND. ECC e LDPC corrigem erros de mídia dentro dos limites da implementação. Quando a margem de correção se esgota, o SSD pode responder lentamente, registrar media errors ou entrar em estados de proteção.
5. Namespace NVMe corretamente explicado
Segundo a NVM Express, namespace é um volume organizado em blocos lógicos e associado a capacidade não volátil. Um controlador pode ter múltiplos namespaces. GPT, MBR, VMFS, NTFS ou LVM podem existir dentro desse namespace. Portanto, recriar namespace não é equivalente a simplesmente recuperar uma partição.
6. U.2, U.3 e EDSFF
NVMe é protocolo, não formato físico. U.2, U.3, M.2, AIC, E1.S e E3.S são formas de implementar SSDs PCIe/NVMe em diferentes plataformas. U.3 e EDSFF aparecem cada vez mais em data centers modernos, enquanto U.2 permanece presente em muitas gerações de servidores.
7. SAS dual-port e multipath
SAS enterprise pode oferecer duas portas independentes para alta disponibilidade. A análise precisa identificar se a falha está no SSD, em uma porta, HBA, expander, cabo ou backplane. Em storage, um caminho sobrevivente pode mascarar degradação da unidade até o failover ocorrer.
8. Firmware e estados de proteção
Fabricantes podem implementar read-only, fail-safe, safe-mode e outras respostas quando detectam condições críticas. Não existe um comportamento universal válido para todos os SSDs enterprise. Em recuperação, o estado deve ser observado e preservado antes de tentar sair dele.
9. Clonagem antes de reconstrução
Quando existe janela de leitura, adquirir individualmente os membros reduz a necessidade de trabalhar sobre o hardware original. Em RAID, reconstrução virtual sobre clones permite testar ordem, stripe, offset e paridade sem escrever nos SSDs.
10. RAID não é apenas paridade
Além de RAID 0, 1, 5, 6 e 10, existem camadas como Storage Spaces, mdraid, ZFS, vSAN e pools proprietários. Hot spare, cache, journals e metadados de controladora podem alterar a ordem aparente dos eventos.
11. Virtualização adiciona novas camadas
Após o array ser reconstruído, ainda pode existir VMFS, ReFS, LVM-thin, ZFS, Ceph ou outro sistema de armazenamento. VMDK, VHDX e QCOW2 precisam ser validados como contêineres lógicos, e aplicações dentro das VMs podem exigir análise adicional.
12. TCG Opal e SED
Em Self-Encrypting Drives, dados brutos podem permanecer cifrados. Preservar controladora, firmware e estado de segurança pode ser tão importante quanto preservar a NAND. Comandos de sanitize e crypto erase devem ser evitados quando a intenção é recuperar dados.
13. Matriz técnica de diagnóstico
| Sintoma | Camada a investigar | Primeira prioridade | Evitar |
|---|---|---|---|
| SSD não aparece | Backplane, alimentação, protocolo, firmware, controladora | Separar falha de caminho e falha do drive | Hot-swap repetitivo |
| Predictive Failure | Health logs, media errors, endurance | Validar backup e adquirir dados | Manter workload intenso |
| Read-only | Firmware, media health, proteção | Aproveitar leitura e preservar | Desbloquear antes da cópia |
| RAID Degraded | Todos os membros e controladora | Mapear estado e slots | Rebuild automático |
| Namespace ausente | NVMe controller, namespace e firmware | Registrar configuração atual | Recriar namespace sem análise |
| SAS em um só caminho | Porta, HBA, expander, SSD | Verificar multipath e logs | Concluir que drive está saudável |
| Datastore offline | SSD, RAID, VMFS/ReFS/ZFS/LVM | Preservar hardware primeiro | Repair ou recriação de volume |
14. Conclusão técnica
Em ambiente enterprise, a recuperação mais segura começa registrando o estado atual e separando cada camada. SSD, backplane, controladora, RAID, pool, datastore e aplicação são partes de uma cadeia. Intervir na camada errada pode alterar evidências necessárias para recuperar a camada seguinte.
Referências utilizadas neste guia
A página da E-Recovery foi usada apenas como benchmark editorial e semântico. As explicações técnicas da SECURITY foram estruturadas de forma original e confrontadas com fontes primárias de fabricantes e especificações.
- ACE Lab: lista atualizada do PC-3000 SSD e formatos suportados
- NVM Express: especificações NVMe e formatos
- NVM Express: namespaces e arquitetura NVMe
- Samsung Semiconductor: SSDs enterprise NVMe e SAS
- Samsung Semiconductor: SSDs data center SATA
- Micron 7450: NVMe, U.3/M.2 e PLP
- KIOXIA CM7-V E3.S: NVMe enterprise
- Solidigm: famílias SSD data center
- Seagate Nytro: SSDs enterprise
