<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 8, 2017 at 4:08 PM Kevin Wolf <<a href="mailto:kwolf@redhat.com">kwolf@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 07.12.2017 um 23:19 hat Nir Soffer geschrieben:<br>
> On Wed, Dec 6, 2017 at 6:02 PM Jason Lelievre <<a href="mailto:jlelievre@folksvfx.com" target="_blank">jlelievre@folksvfx.com</a>><br>
> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > What is the best way to set up a daily live snapshot for all VM, and have<br>
> > the possibility to recover, for example, a specific VM to a specific day?<br>
><br>
> Each snapshot you create make reads and writes slower, as qemu has to<br>
> lookup data through the entire chain.<br>
<br>
This is true in principle. However, as long as the lookup is purely in<br>
memory and doesn't involve I/O, you won't even notice this in average<br>
use cases. Whether additional I/O is necessary depends on whether the<br>
metadata caches already cover the part of the image that you're<br>
accessing.<br>
<br>
By choosing the right cache size values for the use case, it can<br>
normally be achieved that everything is already in memory.<br></blockquote><div><br></div><div>Can you give more details about selecting the cache size?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> When we take a snapshot, we create a new file (or block device) and make<br>
> the new file the active layer of the chain.<br>
><br>
> For example, assuming you have a base image in raw format:<br>
><br>
> image-1.raw (top)<br>
><br>
> After taking a snapshot, you have:<br>
><br>
> image-1.raw <- image-2.qcow2 (top)<br>
><br>
> Now when qemu need to read data from the image, it will try to get the<br>
> data from the top layer (image-2), if it does not exists it will try<br>
> the backing file (image-1). Same when writing data, if qemu need to<br>
> write small amount of data, it may need to get entire sector from a<br>
> another layer in the chain and copy it to the top layer.<br>
<br>
Yes, though for this operation it doesn't matter whether it has to copy<br>
it from the second image in the chain or the thirtieth. As soon as you<br>
do a partial write to a cluster that hasn't been written yet since the<br>
last snapshot was taken, you get to copy data, no matter the length of<br>
the chain.<br></blockquote><div><br></div><div>So do you think keeping 30 snapshots for backup/restore purpose is</div><div>a practical solution with negligible effect on performance? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Kevin<br>
</blockquote></div></div>