É assim que os snapshots do LVM funcionam?

Estou tentando descobrir como os snapshots do LVM funcionam para que eu possa implementá-lo no meu servidor de arquivos, mas estou tendo dificuldade em encontrar algo no google que explique como ele funciona, em vez de usá-lo para um sistema de backup básico.

Pelo que li, acho que funciona mais ou menos assim:

• Você tem um LVM com uma partição primária e muito espaço livre não alocado que não está na partição
• Em seguida, você tira uma captura instantânea e a monta em um novo volume lógico. Os snapshots devem ter alterações, portanto esse primeiro snapshot seria uma cópia inteira, correto?
• Então, no dia seguinte, você tira outro instantâneo (o tamanho da partição deste não precisa ser tão grande) e o monta.
• De alguma forma, o LVM controla os instantâneos e não armazena bits inalterados no volume primário.
• Então você decide que possui instantâneos suficientes e se livra do primeiro. Não tenho ideia de como isso funciona ou como isso afetaria o próximo instantâneo.

Alguém pode me corrigir onde estou errado. Na melhor das hipóteses, acho que não consigo encontrar nada no google.

vgdiplay

obu1: / home / cadeia / home / qps / backup / D # vgdisplay
  --- Grupo de volumes ---
  Nome do VG fileserverLVM
  ID do sistema
  Formato lvm2
  Áreas de metadados 1
  Sequência de metadados n.o 3
  Leitura / gravação do VG Access
  Redimensionamento do status da VG
  MAX LV 0
  Cur LV 2
  Open LV 2
  PV máximo 0
  Cur PV 1
  Ato PV 1
  Tamanho VG 931,51 GB
  Tamanho PE 4,00 MB
  Total PE 238467
  Alloc PE / Tamanho 238336/931,00 GB
  PE grátis / Tamanho 131 / 524,00 MB
  VG UUID qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU

Por que não dá uma olhada na seção de instantâneos do LVM-HOWTO ?

Os instantâneos LVM são sua solução básica de instantâneo "copiar na gravação". O instantâneo nada mais é do que pedir ao LVM para fornecer um "ponteiro" para o estado atual do sistema de arquivos e gravar as alterações feitas após o instantâneo em uma área designada.

As capturas instantâneas do LVM "vivem" dentro do grupo de volumes que hospeda o volume sujeito à captura instantânea - e não a outro volume. Sua declaração "... muito espaço livre não alocado, e não a partição" faz parecer que você pensa que os instantâneos "vivem" fora do grupo de volumes sujeitos a um instantâneo, e isso não é exato. Seu grupo de volumes vive em uma partição do disco rígido, e o volume está sujeito a instantâneos e quaisquer shapshots que você tirou ao vivo nesse grupo de volumes.

A maneira normal como os instantâneos do LVM são usados ​​não é para armazenamento a longo prazo, mas para obter uma "imagem" consistente do sistema de arquivos, de forma que um backup possa ser realizado. Depois que o backup é feito, o instantâneo é descartado.

Ao criar um instantâneo LVM, você designa uma quantidade de espaço para reter as alterações feitas enquanto o instantâneo está ativo. Se forem feitas mais alterações do que você designou, o espaço para o instantâneo se tornará inutilizável e deverá ser descartado. Você não deseja deixar os snapshots espalhados porque (a) eles são preenchidos e se tornam inutilizáveis ​​e (b) o desempenho do sistema é afetado enquanto um snapshot está ativo - as coisas ficam mais lentas.

Editar:

O que os Serviços de Cópia de Sombra de Volume da Microsoft e os instantâneos LVM fazem não são tremendamente diferentes. A solução da Microsoft é um pouco mais abrangente (como é o caso da Microsoft - para o bem ou para o mal, suas ferramentas e produtos geralmente buscam resolver problemas muito grandes em vez de se concentrar em uma coisa).

O VSS é uma solução mais abrangente que unifica o suporte a dispositivos de hardware que suportam snapshots e snapshots baseados em software em uma única API. Além disso, o VSS possui APIs para permitir que os aplicativos sejam desativados por meio das APIs de snapshots, enquanto os snapshots do LVM se preocupam apenas com snapshots - qualquer aplicativo de desativação é seu problema (colocar bancos de dados em estados de "backup", etc.).

Os instantâneos LVM são um exemplo de uma solução de instantâneo de cópia na gravação, como Evan disse. Como ele funciona é um pouco diferente do que Evan sugere, mas não muito.

Quando você tem um volume LVM sem capturas instantâneas, as gravações no volume acontecem conforme o esperado. Um bloco é alterado, e é isso.

Assim que você cria um instantâneo, o LVM cria um pool de blocos. Esse pool também contém uma cópia completa dos metadados LVM do volume. Quando ocorrem gravações no volume principal, como a atualização de um inode, o bloco sendo substituído é copiado para esse novo pool e o novo bloco é gravado no volume principal. Este é o 'copy-on-write'. Por esse motivo, quanto mais dados forem alterados entre a captura de uma captura instantânea e o estado atual do volume principal, mais espaço será consumido por esse conjunto de capturas instantâneas.

Quando você monta o instantâneo, os metadados gravados quando o instantâneo foram tirados permitem o mapeamento dos blocos do conjunto de instantâneos sobre os blocos alterados no volume (ou instantâneo de nível superior). Dessa forma, quando chega um acesso para um bloco específico, o LVM sabe qual acesso de bloco. No que diz respeito ao sistema de arquivos nesse volume, não há capturas instantâneas.

James apontou uma das falhas deste sistema. Quando você tem vários instantâneos do mesmo volume, toda vez que grava em um bloco no volume principal, você potencialmente aciona gravações em cada instantâneo. Isso ocorre porque cada instantâneo mantém seu próprio pool de blocos alterados. Além disso, para longas árvores de instantâneos, o acesso a um instantâneo pode causar um pouco de computação no servidor para descobrir qual bloco exato precisa ser atendido para um acesso.

Quando você descarta um instantâneo, o LVM apenas descarta o pool de instantâneos e atualiza a árvore de instantâneos, conforme necessário. Se o instantâneo descartado fizer parte de uma árvore de instantâneos, alguns blocos serão copiados para o instantâneo de nível inferior. Se for o instantâneo mais baixo (ou o único), o pool será descartado e a operação será muito rápida.

Alguns sistemas de arquivos oferecem instantâneos no sistema de arquivos, ZFS e BTRFS são apenas dois dos mais conhecidos. Eles funcionam da mesma forma, embora o próprio sistema de arquivos gerencie o mapeamento alterado / inalterado. Essa é sem dúvida uma maneira melhor de fazê-lo, pois você pode buscar uma família inteira de instantâneos por consistência, o que é algo que você não pode fazer com o LVM direto.

Você não especifica se está usando Linux ou HP-UX. No HP-UX, você cria um volume lógico e o monta como uma captura instantânea de outro volume lógico. No Linux, você cria um volume lógico como um volume de captura instantânea.

A remoção de uma captura instantânea no HP-UX é feita pela desmontagem do volume; no Linux, isso é feito usando lvremove para remover o volume lógico.

De qualquer forma, as alterações são a única coisa armazenada no seu instantâneo. Quanto mais tempo o snapshot permanecer disponível, mais alterações serão estocadas - e há a chance de ele ser preenchido se não for dimensionado ou liberado corretamente.

A velocidade do acesso ao disco em um volume de captura instantânea é mais lenta do que seria para um volume normal; você deve levar isso em conta.

Os instantâneos LVM são ineficientes, quanto mais instantâneos houver, mais lento será o sistema.

Suporte apenas xfs, pois é o que usamos e o xfs_freeze pode ser usado para interromper o novo acesso ao sistema de arquivos e criar uma imagem estável no disco.

A cópia na gravação é usada para que o espaço do disco seja usado com eficiência.

Você criou um sistema de arquivos em um volume lógico que possui espaço livre para as capturas instantâneas.

Este é um exemplo do FAQ