then they are probably very short bursts (which your other tool catches probably). in the rrd data we only collect the data the kernel gives us and put in in an rrd database, there is not really much possible where we'd put wrong data in. aside from that, as i said, i tested it and it works...
ok, so first, the pve graph is bytes not bit, and second when you choose daily max, note that
the graph will (for each data point) show the maximum of the one minute intervals of the rrd (because it gets consolidated)
so if you had a 10gbit burst for 1 second, it'll only show as a 10 Gbit / 8 /...
yes the community subscription costs 95€/year for a single cpu host and does not only remove the warning popup, but also grants you access to the enterprise repository (more stable/better tested packages)
please check the aggregation? which did you use ? e.g. daily (average)?
also note that you have to multiply the value with the number of seconds in the timeframe (since each point is basically for the complete timeframe until the next)
so if the graph shows e.g. 10M/s at 00:00:00 and 0 at the...
wenn du dem darunterliegendem storage vertraust (und der software ;) ) dann sollte das backup gut sein.
ein verify ist eher gedacht um schleichende datenkorruption auf disks zu erkennen.
(manche filesysteme, zb zfs, haben so etwas schon eingebaut, was das verify noch wenig unnötiger macht)
leeren kann man auf ähnliche art und weise:
for domain in $(pmgsh get /config/domains 2> /dev/null | jq -r '..domain'); do pmgsh delete /config/domains/$domain; done
ansonsten könnte man nur das file direkt schreiben (/etc/pmg/domains) + danach 'postmap /etc/pmg/domains' aufrufen
works here without problems
i tested a more simplified setup:
1 role with only Sys.PowerMgmt
testuser has PVEAuditor on / and sys.powermgmt role on /nodes/somenode
could not shutoff another node with the error:
Permission check failed (/nodes/pve7, Sys.PowerMgmt) (403)
edit: can you post your...
so the schedules for that would be:
job1: 'mon..fri 6..19:30'
job2: 'mon..sat 6..19:40'
job3: 'wed..sun 6..17:50'
the rule here is that each part (minute/hour) act independently and you can choose on which values it triggers