Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Backing up LVM partitions using snapshots



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org