>
> "The problem is if the lvm-thin takes up ALL your available space you
> cannot backup to 'local' (easily accessible) storage, even if you wanted
> to with said VM running.
>
Who wants to make Backups to the local Device? It make no sense at all.
For Backups you have to chose a attached
On 02/09/16 07:55, Dietmar Maurer wrote:
>> I still think that for at least single server installs lvm-thin is not
>> necessarily the best default option, and there should possibly be more
>> warning for some to RTFM before hitting go for a default install.
>
> I do not really think this is
> I still think that for at least single server installs lvm-thin is not
> necessarily the best default option, and there should possibly be more
> warning for some to RTFM before hitting go for a default install.
I do not really think this is related to lvmthin. Seems your data
is simply damaged
On 01/09/16 16:38, Dietmar Maurer wrote:
>>> restore your data with that copy (I would not touch the original disks).
>>>
>>
>> Yup, I can see that would be a possibility, if you could get to the
>> disks easily a 1000 miles away buried in a data centre :-)
>
> Maybe the can put a another
> > restore your data with that copy (I would not touch the original disks).
> >
>
> Yup, I can see that would be a possibility, if you could get to the
> disks easily a 1000 miles away buried in a data centre :-)
Maybe the can put a another disk into the server?
On 01/09/16 13:27, Dietmar Maurer wrote:
>> What is worrying is
>>
>> a) there is no effective way to back up a VM if you cannot mount the
>> partition
>
> The basic idea of backup is that you do the backup "before" you have
> a data loss ...
>
Yes, very droll ROFL.
I should really have
> You can still copy the whole disk and then try to do the
> restore your data with that copy (I would not touch the original disks).
corrected version: You can still copy the whole disk - then
try to restore your data using that copy.
___
pve-user
On 01/09/16 12:19, John Crisp wrote:
>> But John wrote:
>>
>>> There was an issue with the BBWC on the RAID
>>
>> So it is likely that more than this is damaged (what happened exactly?)...
>>
>
> Extremely unlikely.
Hmmm... well after further investigation we don't think it was the BBWC
issue.
Hi Dietmar
On 01/09/16 08:38, Dietmar Maurer wrote:
>> In reply to Dietmar in absence of John:
>>
>> root@pve:~# lvchange -a y pve/data
>>Thin pool transaction_id is 0, while expected 3.
>
>
> Does it help if you reboot the node?
>
No - we tried that (it's a single machine/node - no
> In reply to Dietmar in absence of John:
>
> root@pve:~# lvchange -a y pve/data
>Thin pool transaction_id is 0, while expected 3.
Does it help if you reboot the node?
Some people reported that is possible to fix this with vgcfgbackup/vgcfgrestore,
but you should be really careful when
In reply to Dietmar in absence of John:
root@pve:~# lvchange -a y pve/data
Thin pool transaction_id is 0, while expected 3.
root@pve:~# lvs
LVVG Attr LSizePool Origin Data% Meta% Move
Log Cpy%Sync Convert
data pve twi---tz-- 5.34t
data_meta0pve
> root@pve:/etc/pve/nodes/pve/qemu-server# lvs
> LVVG Attr LSizePool Origin Data% Meta% Move
> Log Cpy%Sync Convert
> data pve twi---tz--5.34t
> data_meta0pve -wi-a-4.00m
> root pve -wi-ao 96.00g
> swap pve -wi-ao
Earlier today we had a working Prox 4.2.2 installation
There was an issue with the BBWC on the RAID that was fixed by the data
centre.
After we restarted the machine (and apparent successful shutdown of the
VM) we found that the VMs failed to start with the type of error as
detailed below.
The
13 matches
Mail list logo
