스냅샷의 원리를 생각해야됩니다. 전체 상태를 저장한다라고 생각하시면 나중에 물먹을수 있습니다.
스냅샷을 데이타베이스의 트랜잭션의 시작이라고 비유할수 있습니다.
개발자나 업무 담당자들이 항상 뭔가를 수정하고 업데이트 할때
begin tran 선언을 먼저 합니다. 그러고 난후에 update level 8 어쩌고 저쩌고 하면 주르룩 데이터가 변경이 되죠. 그런데 아차다 싶은겁니다. where 를 안줬네? 롤백 롤백인겁니다. 트랜잭션 시작 선언 안해주면 나중에 대박 장애보다 더 심각한 장애를 경험하게 되는 케이스가 바로 트랜잭션인겁니다.
가상화의 스냅샷도 마찬가지입니다. 뭔가 시스템 설정 변경이나 레니스트리 변경이 필요해서 스냅샷을 찍었습니다. 변경 수정해서 별탈 없으면 상관없지만 별탈이 있어버리면 트랜잭션 이전의 상택로 롤백을 해야되는거죠.
자 그럼 트랜잭션을 발생시키면 DB에서는 수정되는 테이블에서 락이 발생되어 뒷단에서 데이터 변경이 큐가 무지 많이 쌓일거고 빨리 커밋을 날려주든가 아니면 롤백을 하던가 해야됩니다. 깜빡하고 커밋 안해주면 인프라의 악당이 되는거죠. 친한 개발자한테 자주 드는거지만 강아지 된답니다. ㅋㅋㅋ
스냅샷도 오래 놔두면 현재 디스크 상태에서 변경된 부분들이 계속 증가되기 때문에 데이터가 무지 많이 쌓이게 됩니다. 스냅샷도 빨리 지워줘야지 오래 놔두면 이것또한 재앙을 불러올수가 있습니다.
스냅샷 이후에 생성된 데이터와 이전의 디스크 데이터가 제대로 합쳐지지 않으면 나중에 몇달치이상 1년 이상의 데이터를 한큐에 날려버릴수도 있는 경우도 있습니다.
스냅샷을 너무 신뢰하는 추세가 있는데 스냅샷 때문에 시스템이 올라오지 않는 현상 경험하면 두번다시 찍고 싶지 않을수도 있습니다. 차라리 백업을 하지 스냅샷은 안찍는다는...
1. 스냅샷은 백업이 아닙니다. 단 백업용으로 사용하기도 하지만 일반적으로 현업에서 1일간에 복구시 사용합니다.
시간마다 찍으면 24본에 백업본이 생기니까요. 물론 별도에 백업은 별도로 긴밖에 상황에서 빠른 복구
2. VMware 스냅은 백업할때 사용합니다. VStorage API를 사용하는 경우 일반적으로 사용 백업 S/W에서 주로 사용합니다. 스냅을 걸고 그 시점으로 받습니다. 물론 스냅시 윈도우에 VSS기능도 같이 사용합니다. 이거는 OS파일보다는 DB파일이 정합성
3. V모션 등 다양한 상황에서 스냅샷을 사용합니다
4. VMWARE 생성시 데이타스토어에 여유용량이 권장은 30%입니다. 이것은 스냅샷때문이라고 생각하시면됩니다.
5. 일반적인 외장 스토리지에서 스냅샷용량은 20%으로 산정하는게 일반적입니다.
6. 스냅샷으로 복구 가능하며 테스트본 생성, 패치등에 많이 사용합니다.
7. 스냅샷은 따로 지우실 필요없습니다. 시간이 지나면 덥어 씨우니 관리 안하셔도 됩니다. 단 스냅샷 찍은지 오래된경우 디스크 사용량에 따라 지워집니다. 따로 관리 안하셔도 문제 전혀 없습니다. 그냥 옛날 스냅샷만 지워집니다.
(디스크에 내부에서 이렇게 되고 VMware Esxi에서 따로 지워야죠)
vmware 및 일반적으 COW(copy on write)을 방식을 사용합니다. 다른 방식도 있으나 일반적입니다.
1) 블럭단위로 스냅샷 생성
2) 블럭이 쓰여질때 현재 블럭데이터를 스냅샷 위치로 저장
3) 리드시는 이존 블럭에서 읽고, 스냅샷 볼륨을 읽을 때는 기존블럭과 변경된부분은 임의에로 저장된 스냅샷 블럭에서 읽는 방식입니다.
대충 써서 그런지 이해는 안 됩지만 스냅샷과 백업등을 혼용하시는 오류는 범하시면 안 됩니다.
VMware 스냅샷은 안정되고 좋은 스냅샷입니다. 스냅샷에 이해를 잘 하시면 아주 활용 좋은 기능이며 이해를 제대로 하고 사용하기를 권장합니다.
단 너무 오래 보관하면 안됩니다.'
제일 중요한거 관리가 많이 필요없다 하지만 너무 많이 찍지 마십시요. 어느정도 관리는 필요합니다
단 메모리 스냅샷을 활성화 하지 않으면 그 '실행 당시의 시점'으로 돌아가는 것은 아니라고 알고 있습니다.
메모리 스냅샷을 한번 찍을 때 마다 시스템 메모리 용량만큼의 디스크를 차지하기에 저는 끄고 사용중입니다.
시스템이 망가졌을 때 복구하는 용도로는 일반 스냅샷을 써도 상관 없기에..
스냅샷을 데이타베이스의 트랜잭션의 시작이라고 비유할수 있습니다.
개발자나 업무 담당자들이 항상 뭔가를 수정하고 업데이트 할때
begin tran 선언을 먼저 합니다. 그러고 난후에 update level 8 어쩌고 저쩌고 하면 주르룩 데이터가 변경이 되죠. 그런데 아차다 싶은겁니다. where 를 안줬네? 롤백 롤백인겁니다. 트랜잭션 시작 선언 안해주면 나중에 대박 장애보다 더 심각한 장애를 경험하게 되는 케이스가 바로 트랜잭션인겁니다.
가상화의 스냅샷도 마찬가지입니다. 뭔가 시스템 설정 변경이나 레니스트리 변경이 필요해서 스냅샷을 찍었습니다. 변경 수정해서 별탈 없으면 상관없지만 별탈이 있어버리면 트랜잭션 이전의 상택로 롤백을 해야되는거죠.
자 그럼 트랜잭션을 발생시키면 DB에서는 수정되는 테이블에서 락이 발생되어 뒷단에서 데이터 변경이 큐가 무지 많이 쌓일거고 빨리 커밋을 날려주든가 아니면 롤백을 하던가 해야됩니다. 깜빡하고 커밋 안해주면 인프라의 악당이 되는거죠. 친한 개발자한테 자주 드는거지만 강아지 된답니다. ㅋㅋㅋ
스냅샷도 오래 놔두면 현재 디스크 상태에서 변경된 부분들이 계속 증가되기 때문에 데이터가 무지 많이 쌓이게 됩니다. 스냅샷도 빨리 지워줘야지 오래 놔두면 이것또한 재앙을 불러올수가 있습니다.
스냅샷 이후에 생성된 데이터와 이전의 디스크 데이터가 제대로 합쳐지지 않으면 나중에 몇달치이상 1년 이상의 데이터를 한큐에 날려버릴수도 있는 경우도 있습니다.
스냅샷을 너무 신뢰하는 추세가 있는데 스냅샷 때문에 시스템이 올라오지 않는 현상 경험하면 두번다시 찍고 싶지 않을수도 있습니다. 차라리 백업을 하지 스냅샷은 안찍는다는...
1. 스냅샷은 백업이 아닙니다. 단 백업용으로 사용하기도 하지만 일반적으로 현업에서 1일간에 복구시 사용합니다.
시간마다 찍으면 24본에 백업본이 생기니까요. 물론 별도에 백업은 별도로 긴밖에 상황에서 빠른 복구
2. VMware 스냅은 백업할때 사용합니다. VStorage API를 사용하는 경우 일반적으로 사용 백업 S/W에서 주로 사용합니다. 스냅을 걸고 그 시점으로 받습니다. 물론 스냅시 윈도우에 VSS기능도 같이 사용합니다. 이거는 OS파일보다는 DB파일이 정합성
3. V모션 등 다양한 상황에서 스냅샷을 사용합니다
4. VMWARE 생성시 데이타스토어에 여유용량이 권장은 30%입니다. 이것은 스냅샷때문이라고 생각하시면됩니다.
5. 일반적인 외장 스토리지에서 스냅샷용량은 20%으로 산정하는게 일반적입니다.
6. 스냅샷으로 복구 가능하며 테스트본 생성, 패치등에 많이 사용합니다.
7. 스냅샷은 따로 지우실 필요없습니다. 시간이 지나면 덥어 씨우니 관리 안하셔도 됩니다. 단 스냅샷 찍은지 오래된경우 디스크 사용량에 따라 지워집니다. 따로 관리 안하셔도 문제 전혀 없습니다. 그냥 옛날 스냅샷만 지워집니다.
(디스크에 내부에서 이렇게 되고 VMware Esxi에서 따로 지워야죠)
vmware 및 일반적으 COW(copy on write)을 방식을 사용합니다. 다른 방식도 있으나 일반적입니다.
1) 블럭단위로 스냅샷 생성
2) 블럭이 쓰여질때 현재 블럭데이터를 스냅샷 위치로 저장
3) 리드시는 이존 블럭에서 읽고, 스냅샷 볼륨을 읽을 때는 기존블럭과 변경된부분은 임의에로 저장된 스냅샷 블럭에서 읽는 방식입니다.
대충 써서 그런지 이해는 안 됩지만 스냅샷과 백업등을 혼용하시는 오류는 범하시면 안 됩니다.
VMware 스냅샷은 안정되고 좋은 스냅샷입니다. 스냅샷에 이해를 잘 하시면 아주 활용 좋은 기능이며 이해를 제대로 하고 사용하기를 권장합니다.
단 너무 오래 보관하면 안됩니다.'
제일 중요한거 관리가 많이 필요없다 하지만 너무 많이 찍지 마십시요. 어느정도 관리는 필요합니다
스냅샷을 찍고 파워온 스위치를 누르면 켜져야 하는데 켜지지가 않습니다.
백 시켰는데 그것도 안켜지고요...
답변 주신분들 감사합니다.
스냅샷때문에 시스템이 안올라오는건 이미지 핸들링 되는거 다 없애고 삭제해서 올릴수도 있어요.