Search results

They are only warnings and not errors. It isn't necessary to address them but if you want to, the options as I remember it are: 1. Set explicit gran_size & chunk_size options in kernel boot parameters. In /etc/default/grub append to GRUB_CMDLINE_LINUX_DEFAULT. This will prevent the verbose...

With an integrated GPU, you may find that changing the amount of RAM assigned to it in the BIOS (and consequently the amount of system RAM) will help the kernel determine optimal values of gran_size & chunk_size.

Oh yes. However the significance of that file slipped my notice because I was unaware of how it was involved in presenting the contents of /etc/pve. root@odin:~# systemctl stop pve-cluster.service root@odin:~# ls -l /etc/pve/ total 0 FWIW my backup strategy now, since I do not run a cluster...

Thanks @Dunuin. With the pve root fs being on a logical volume, I wonder if it's possible to do an lvm snapshot and make that the source of your block level backup to PBS?

Do you perform the root fs block level backups on running system? Also how do you go about restoring a PVE root fs from block level backup stored on PBS?

Thanks. for that info. I was aware that /etc/pve was a fuse mount backed by the proxmox userland application. I didn't know that that sqlite file was part of it. So, if one were to restore config to a non-running PVE system, they must restore that sqlite db. I have added it to my rsnapshot config!

Due to the versatility of setup, I'm wondering if such a one size fits all system backup/restore utility for PVE is feasible.

I understand that /etc/pve is critical. However mention has been made of /var/lib/pve-cluster. Whilst it appears to store config data, I was under the impression it was part of the running state of PVE and not critical to backup. Is that correct? I have not yet used my backup to restore on top...

Some of these solutions seem over complex to me but I may be missing something. My PVE host backup strategy has been to create simple backup archives that are easy to use should I need to selectively restore config: rsnapshot /etc/ (one_fs=0), /root, /usr/local (where I try to make a point to...

For some foolish reason I was only looking at the headers for a TLD. I found the culprit in the message body.

I've a few emails that score with: KAM_SOMETLD_ARE_BAD_TLD 5 .bar, .beauty, .buzz, .cam, .casa, .cfd, .club, .date, .guru, .link, .live, .online, .press, .pw, .quest, .rest, .sbs, .shop, .stream, .top, .trade, .work, .xyz TLD abuse However I don't see where the emails concerned match this...

Yes, I do. No errors. INFO: HOOK: job-end INFO: HOOK-ENV: dumpdir=/mnt/pve/omv-backup/dump;storeid=omv-backup; INFO: HOOK: storage: nfs /mnt/pve/omv-backup INFO: HOOK: job-end umounted /mnt/pve/omv-backup INFO: Backup job finished successfully

Well I don't think the directory ever gets unmounted. When I run the backup, whilst running another shell in the mounted fs, no errors occur. Ordinarily attempting to umount it under those circumstances should fail. I'm going to keep plugging away and may redo the hook script with bash rather...

pvesm status shows the store as disabled once job completes and I can successfully umount the NFS export (manually using umount directly or running relevant perl snippet from the hookscript). Here are relevant parts of config and journal output as well as mounts before and after job runs: #...

It seems umount, called from the hook script, has no effect. That, or the pve daemon immediately remounts it for some reason. The system call to umount in my hookscript (job-end phase) is successful in so far as it returns success (0). However checking mount and directory listing after the job...

I felt wrong invoking perl via system from within a perl script. Incidentally after posting I just found I could do this my $cfg = PVE::Storage::config(); my $fstype = $cfg->{'ids'}{$storeid}{'type'}; my $mountpoint = $cfg->{'ids'}{$storeid}{'path'}; but haven't tested anything. However I'm...

I just realised that disabling storage does not umount the NFS volume. Now I am attempting something like this in my hookscript: if (($phase eq 'job-end') || ($phase eq 'job-abort')) { my $mountpoint = system ("pvesh get storage/$storeid --noheader 1 --noborder 1 | grep ^path | awk...

Just what I need. I had no idea you could set script on specific jobs. Many thanks!

Thanks. I look forward to it. So once implemented, absence of a shedule will mean we can infer it was run from the web UI or cmdline. This was my first experience with PVE hooks. I wanted to (un)mount remote storage on demand. But not unmount if the script had been invoked via non-scheduled backup.

Within a vzdump hook script, how can I differentiate scheduled backups from those run interactively via the web UI? There doesn't appear to be anything in env I might use to do this.