Search results

I guess the other way around is an option : add the Ceph storage of the old cluster as a remote Ceph on the new host, stop the VM on the old cluster and start it on the new host from the Ceph storage, then live move the disk to the ZFS storage

I no longuer work in this company and sadly, it looks like my former employer decided to close access to all the repos.

Before ranting, please take a closer look at the license under which PVE is released (and look for the warranties). Keep in mind a lot (most ?) users were able to handle the upgrade with no issue (including myself, on several servers). Major upgrades of any system requires basic administration...

Hard to tell. Could be a failing disk on either the source or the destination. You should check the system logs

You can install PBS on PVE already, it's not required to install it on a separate host

What would be the benefit compared to PBS ?

You should delete the actual RAID configuration (delete the VD again), then re-create the VD exactly as it was previously (same set of physical drives, in the same order, with the same chunk size etc. Everything must be exactly the same). Be careful not to initialize the VD when recreating it...

Depends on your RAID card if you'll be able to expand the RAID6 array with more PD. But at least, you might be able to get your data available, back them up, wipe and recreate the array on all the disks, and restore

You should recreate the RAID array with the exact configuration as it was previously (same PD, same order, same chunk size etc.)

This is most likely because you have a weekly fstrim job running, which will mark all the trimmed sectors as dirty. It shouldn't affect backup speed that much as all those "dirty" sectors will not really be red from disk

In the doc, but also already tried ;-)

Proxmox will self-fence the isolated host : host1 will be forcibly rebooted, so VM100 is for sure not running anymore. While host1 is rebooting, VM100 will be relocated to either host2 or host3

You can also check/replace the SATA cable. A bad one could also explain this kind of errors. In any case, it's most likely a hardware problem.

Your HDD or SSD /dev/sda is failing, you should replace it

That'd requier a lot of spare space, cpu and memory resources, and overall doesn't look like the proper way to handle the problem

Lastlog can't be rotated, and it's a binary file. If it's removed, it'll be recreated with the same size (and still sparse). IMHO the only reasonable thing to do is to exclude it from backups

You can do it creating /var/log/.pxarexclude containing a single line : lastlog (haven't tried, just red the doc)

So just exclude /var/log/lastlog from your backups and you should be fine

I mean, it could be sparse files present in the CentOS 7 CT, but not in the others

Couldn't large sparse files inside those CT explains it ? I had similare issues with AD domain members having huge sparse /var/log/lastlog files