Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Wed, Dec 14, 2011 at 10:53 AM, Richard Pieri <richard.pieri at gmail.com> wrote: > On Dec 13, 2011, at 11:11 PM, markw at mohawksoft.com wrote: >> >> Using a block level store, an incremental backup is no different than a full backup. > > You're not following me. ?You have a full dump. ?You have a first differential against that dump. ?You have a second differential made against the first differential. ?If you lose the first differential then you are screwed. I've been watching the (second?) incarnation of this thread for a while now and I think that I see your point. I wonder if the "TRIM" functionality that is being added to filesystems in order to handle SSDs could help with this. Filesystems with high churn rates are likely to see lots of data blocks (but probably not meta-data blocks) get TRIMmed. If snapshots kept track of this in some fashion it might become cheap enough to just do differentials against the original full dump rather then against earlier differentials. This would seem to substantially reduce your concerns about data loss. This wouldn't help with single file restore although file level backup systems that do incremental backups can require you to go through a pile of tapes unless they keep a database of filenames/versions/tapes. Does anybody know if LVM pays attention to TRIMs at all? At this point, this is idle speculation on my part. I haven't researched or thought it through. Bill Bogstad
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |