음.. 대충 이해한걸로는
하드 데이터 복구랑 비슷한 기분?
파일이 삭제 되거나 수정하면
다른 inode에 저장/삭제를 할 텐데
file system 레벨에서
그걸 삭제한게 아니라 version history 관리하듯
촤르륵 목록으로 냅두고 실제로 삭제하지 않음으로서
inode 목록만 저장(snapshot) 해두고
그걸로 이전의 시간대로 복구하는 개념..
CoW(Copy on Write) 는 스냅샷을 구현하는 방법론이 되려나?
[링크 : http://hybridstoragekorea.blogspot.com/2013/10/blog-post_4204.html]
| Snapshot technology | ||||||
| Copy- on-write | Redirect- on-write | Clone/ split mirror | COW w/back- ground copy | Incremental | CDP | |
| Snapshot is tightly coupled to original data | Yes | Yes | No | Yes, until background copy finishes | Depends on how original snapshot is generated | No |
| Space efficient | Yes | Yes | No | No | No | Yes, versus multiple point-in-time snapshots |
[링크 : http://searchdatabackup.techtarget.com/...snapshot-technologies-for-data-protection]
고민을 해보니.. SSD에서는 구현 못하는거 아냐? inode가 붕뜨면 삭제처리 할텐데?(Trim)
했는데.. fs 레벨에서 inode 삭제가 아니라 삭제된 inode로 다른 테이블에서 실 데이터로 관리해주면
trim에 의해서 삭제 되지 않을테니 문제 없음! 이 될 것 같고
하드 공간이 넉넉하지 않으면 엄청난 성능 저하 및
snapshot으로 복구 할 가능성이나 시간대역이 짧아질 문제가 있을 것으로 보인다.
만약.. 4T 하드에 3T 내용이 있고
그 내용 전부를 크립토락커로 당했다면.. 전부 복구가 불가능 해질 가능성도 존재할 것으로 생각이 된다...
(아니면 말고..)
한마디로.. 삭제 된 파일도 실제 FS 상에서는 .remove 식으로 관리해둔다고 보면 될 듯?(리눅스 기준)
+
저널링은 갑작스런 전원 중단으로 인한 불일치를 복구하는데 유리한 시스템이고
(commit이 완료되면 엎어씀)
스냅샷은 엎어쓰지 않아서 정전과 상관없는 백업을 유리하게 하는 시스템..
Versioning file systems should not be confused with journaling file systems. Whereas journaling file systems work by keeping a log of the changes made to a file before committing those changes to that file system (and overwriting the prior version), a versioning file system keeps previous copies of a file when saving new changes. The two features serve different purposes and are not mutually exclusive.
'이론 관련 > 컴퓨터 관련' 카테고리의 다른 글
| h.264 헤더 (0) | 2016.02.02 |
|---|---|
| RAID6 (2) | 2016.01.28 |
| tsl - test and set lock (0) | 2015.11.23 |
| SNTP - Simple NTP (0) | 2015.11.12 |
| MMIO <-> PMIO (0) | 2015.07.28 |
