<html><head></head><body><br>
Thanks for the info on the collie commands.<br>
<br>
I think the key advantage to having a "canonical" backup store would be that you didn't have to stress the collie cluster with backup requests because the data would already be on that one unit. With the data multicasting around, it seems a shame to run up the cluster for a redundant request if we could create the node that stores it all by default.<br>
<br>
The consistecy issue is not something I'm seeking to solve with this as it seems that would need client participation and be outside the realm of sheepdog.<br>
<br>
<br>
pace<br>
--<br>
...sent from mobile, please excuse...<br><br><div class="gmail_quote">"Frank Matthieß" <f4m8at@googlemail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">Hello Mark,<br /><br />[Mark Pace, Freitag 07 Oktober 2011 06:30]:<br />> Hello everyone. I've been following the development and have been<br />> testing sheepdog in a limited environment. My key concerns (beyond<br />> stability) revolve around offline/offsite backing up. I'd like to<br />> achieve the following somehow, albeit with built in sheepdog<br />> functions or functions that are pushed into qemu-img.<br />> <br />> 1. Offline backups: Right now sheepdog offers redundancy, but there<br />> needs to be a way to store consistent offline backups. Being<br />> able to have a node that stored complete copies of images that could<br />> then be copied from that location would be ideal. For example,<br />> could a special node would participate in the cluster as a mechanism<br />> for making backups? You could go to this node and see the current<br
/>> copy of each image (regardless of how many copies you configured,<br />> this node would have complete copies of every stored virtual). You<br />> could then use file system snapshotting to make copies of these<br />> files for offline/offsite/cloud storage<br /><br />From my view it would be enough to get snapshots from the images, which <br />can be copied to a backup media. <br /><br />The problem here is to get a *consitend* snapshop from the guest os <br />view. This is the hard part. <br /><br /><br />> 2. Images/snapshots to files: a mechanism to take a snapshot or a<br />> regular image out of the sheepdog cluster to turn it into a file<br />> for backup, to be sent to a customer, stored on a hard drive, etc. <br />> This may already exist in qemu-img, but I don't know how easy it is<br />> to take a snap and turn it into a full image. This is more of a one<br />> off thing than the first point, but is necessary none-the-less. I<br
/>> see that qcow2 images can be created from snapshots using a<br />> relatively new (or a least the site I read claimed it was relatively<br />> new) feature of the qemu-img convert functionality -- does sheepdog<br />> also support this?<br /><br />At least from version 0.2.4, which is released yesterday, the collie <br />command will give you the ability to read and write to sheepdog <br />blockstorage.<br /><br />Backup:<br /># collie vdi snapshot VolumeName -s BackupVolumeName<br /># collie vdi read VolumeName -s BackupVolumeName > BackupFile<br /><br />will do the job.<br /><br />Frank.<br />-- <br />Frank Matthieß Mail f4m8at@googlemail.com<br /> G+ <a href="http://gplus.to/fmat">http://gplus.to/fmat</a><br />-- <br />sheepdog mailing list<br />sheepdog@lists.wpkg.org<br /><a href="http://lists.wpkg.org/mailman/listinfo/sheepdog">http://lists.wpkg.org/mailman/listinfo/sheepdog</a><br
/></pre></blockquote></div></body></html>