<div dir="ltr"><div><div><div><div><div><div><div>Sure it is, but :<br></div>  we will make one copy per week, like a full backup<br></div>  we will make backup of datas in a classical way (rsync or something similar...)<br><br></div>So we plan to use it as a far recovery process (wich provide a base machine). It doesn' t allow us to bypass backup, just a way to quick recover services...<br><br></div>More, only file server has changing files, others are TSE they stay relatively stable on time, and loosing one week of change is better, that being blocked during one day... So we are<br><br></div>Everything is a couple of choices, nor the best, nor the worst....<br><br></div>Ideas are welcome...<br><br></div>Serge<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-15 17:22 GMT+02:00 Michael Rasmussen <span dir="ltr"><<a href="mailto:mir@datanom.net" target="_blank">mir@datanom.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 15 Oct 2014 17:02:25 +0200<br>
Serge NOEL <<a href="mailto:serge.noel2008@gmail.com">serge.noel2008@gmail.com</a>> wrote:<br>
<br>
> Exactly, we are working on disaster scenarii and we want to find quick<br>
> solution in case of SAN failure.<br>
> In this case, we imagine that SAN will be unavailable, and we hope to be<br>
> able to restart with NAS (iSCSI) as replacement target, if we are able to<br>
> make copy of all VM, (it seems OK, i tried to copy lvm volume group with dd<br>
> : it's works) during normal operations. Doing so, in case of failure, all<br>
> we have to do is : to say to Proxmox to use disk from different iSCI (or<br>
> NFS) target.<br>
</span>Isn't that dangerous? I mean your approach will surely cause the loss<br>
of data since all changes between the time of creation of the fall-back<br>
disk an the incident will be lost!<br>
<br>
If you need uptime like 99.999% you should drop you single point of<br>
failure SAN an move on to clustered storage since clustered storage is<br>
the only viable solution to your high demand on uptime.<br>
<br>
--<br>
Hilsen/Regards<br>
Michael Rasmussen<br>
<br>
Get my public GnuPG keys:<br>
michael <at> rasmussen <dot> cc<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E" target="_blank">http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E</a><br>
mir <at> datanom <dot> net<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C" target="_blank">http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C</a><br>
mir <at> miras <dot> org<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917" target="_blank">http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917</a><br>
--------------------------------------------------------------<br>
/usr/games/fortune -es says:<br>
This fortune intentionally says nothing.<br>
<br>_______________________________________________<br>
pve-devel mailing list<br>
<a href="mailto:pve-devel@pve.proxmox.com">pve-devel@pve.proxmox.com</a><br>
<a href="http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel" target="_blank">http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel</a><br>
<br></blockquote></div><br></div>