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 2:00 PM, Richard Pieri <richard.pieri at gmail.com> wrote:
> On 12/14/2011 12:34 PM, Bill Bogstad wrote:
>>
>> 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.
>
>
> I don't think so. ?The problem I describe is that once a dump goes missing
> then any differentials against it will have inconsistencies between the file
> data and the file metadata structures. ?TRIMming freed blocks won't make
> this go away. ?It might make things worse what with dangling inode lists
> pointing to de-allocated SSD blocks.

Let me try again.   1. Do away with differentials against
differentials.  2.  Optimize differential against full by keeping
track of TRIMs so that writes that are later TRIMed are dropped from
the list of differences from full.   Since any restore would be simply
full + one differential there shouldn't be any inconsistencies.

My hope would be that TRIM would make at least some of the churn in
the data blocks go away which would make up for the cost of always
doing differential against full backups.   This would obviously depend
on file churn and how the filesystem decides to allocate disk blocks.
Note: I am NOT suggesting that LVM or Mark's program work this way.
Just that it might be a way to design such a system.

> As an aside, enterprise backup systems like Amanda and Bacula and TSM do,
> indeed, maintain databases of backed up files and what media they are on.

Been there, done that.  Of course, when that database gets corrupted
recovering even a single file from a file oriented backup system means
you start scanning a bunch of tapes.  Some systems like to backup the
database every time any kind of backup occurs.   This can get
expensive if you have lots of small files or you keep your history for
a long time.

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