Backup error with space available
-
I still have HTTP timeouts on the backup. The quantity is less however.
-
@Bane Have you tried increasing the timeout length?
-
Yes, that has been done. The most recent builds Olivierlambert suggested have reduced the issue, just not fixed it completely.
-
@Bane Sorry if I wasn't clear. I meant to further increase it from the initial solution provided. What happens if you change
1800000to3600000? -
@Danp I've doubled it and I'm retrying the backup.
-
It looks like changing the time out to 60 minutes has fixed my backup issue. So, the next question.
Is it possible to restore the VM backups to a different install of XCP-NG? I have a single XCP-NG server and would like to re-install XCP-NG and set it up for XCP to be on smaller hard drive and all my VM storage to be on a ZFS RAIDZ1.
-
That's one great thing about virtualization and XO backup: it doesn't matter where do you restore your backups. Doesn't matter in terms of hardware, storage, network.
You can restore all your backup on freshly installed machines or old stuff, regardless what's inside.
-
Where would the timeout fix be applied in community edition? There is not a /etc/xo-server directory.
Thanks,
-
@olivierlambert I'm also trying to restore the VM's that were successfully backed up. I have two that fail to restore and give the error:
IMPORT_ERROR_PREMATURE_EOF()
What can I do to determine what this failure means? I found a previous entry about disk space, but I do not have any disk usage issues that I can see.
Filesystem Size Used Avail Use% Mounted on devtmpfs 2.8G 12K 2.8G 1% /dev tmpfs 2.8G 268K 2.8G 1% /dev/shm tmpfs 2.8G 10M 2.8G 1% /run tmpfs 2.8G 0 2.8G 0% /sys/fs/cgroup /dev/nvme0n1p1 18G 1.9G 15G 12% / xenstore 2.8G 0 2.8G 0% /var/lib/xenstored /dev/nvme0n1p5 3.9G 83M 3.6G 3% /var/log /dev/nvme0n1p4 512M 3.0M 509M 1% /boot/efi tmpfs 571M 0 571M 0% /run/user/0 tank 4.3T 256K 4.3T 1% /tank tank/local-store 4.3T 17G 4.3T 1% /tank/local-store //192.168.2.15/iso 22T 15T 6.5T 70% /run/sr-mount/39ac011c-a02a-d9bb-0fef-7fffebbefaccThanks
-
- It's not a fix, it's just a workaround. It's not normal to have this kind of timeout
IMPORT_ERROR_PREMATURE_EOF()means the backup is maybe incomplete or import stalled
- It's not a fix, it's just a workaround. It's not normal to have this kind of timeout
-
Is there anyway to determine whether it's a failed backup or stalled import? Is there anything that can be done to correct a stalled import? I assume there is nothing that can be done for it if it's a failed backup..
Also interesting is that the restores that fail are listed with a number instead of the VM name.
-
It's really hard to tell without being inside the infrastructure
-
Any logs inside XCP-NG that I can look at? I've resigned myself to the fact that I will have to rebuild the two VM's that won't import, but I'd like to prevent a similar situation in the future.
-
Are you using XOA or XO from the sources? In any case, be sure you be entirely up to date (on
latestor latest commit) -
I have both installed to try out community. I am performing the restore from XOA, the same console I used for the backups.
Incidentally, I would pay for the XOA, but $70 a month to get back up for my home lab is a bit pricy, I only have one server. You guys might consider offering a paid version with backup that maybe doesn't include premium support for a reduced price. I can't speak for anyone else, but I would be willing to pay for something like that, to have a turnkey solution with easy updates and backup.
-
XOA isn't meant for individuals but only companies
We can go below $70 because it's not even profitable at this price already.edit: when I said try with XOA, I'm not suggesting to pay for it! Just go for the trial, to see if it works there. If it is, it might tell that's a build problem on your side
-
XOA is what I have been trying. I have not tried the restore in community.
-
So the backup was also made with XOA in the first place?
-
That is correct.
-
You should probably open a support ticket with a support tunnel so we can take a look remotely.
