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

Re: [Xen-users] Backup running Windows machines - redundancy


  • To: Guido Hecken <guido.hecken@xxxxxxxxxxxxx>
  • From: Mike Sun <msun@xxxxxxxxxxxx>
  • Date: Thu, 10 Feb 2011 16:50:25 -0500
  • Cc: Paul Piscuc <paul.piscuc@xxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 11 Feb 2011 09:08:34 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jeawIsR50opR8ljyzkYa84eCpsZ3NZxzvHx1gibNJwQDNq9I4HZoup/nYpo7FVCrE9 ge/AqSYHTf8uusF0sIkmBk1Mi52kQGORdGXqHE6As65J+iD5FG8KtfzNJgABlcuWN759 rNfjRUb0ja2abUGbkEr1GwxUUb5HHbaU+C3Pc=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

> I did some tests on different tools like ntfsclone, partimage and dd through 
> gzip.
> In combination with LVM Snapshots they produce a backup which should preserve 
> all meta data since these
> methods are not filebased.
> One of the disadvantages are, these are not increment backup solutions, so 
> you will have multiple big archive
> files.

What if you used file-backed sparse images as the VM's virtual disk
and then used rsync/rdiff-backup on that file itself?  That way, you
don't have to worry about rsync/rdiff-backup being aware of NTFS
metadata, but still take advantage of the incremental binary diffs
that rsync/rdiff-backup provide at the file level.

Is that a feasible solution?

Mike

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.