Search results

maybe your hardware have the same iommu group ? root@pve10g:~# find /sys/kernel/iommu_groups/ -type l /sys/kernel/iommu_groups/7/devices/0000:00:1b.0 /sys/kernel/iommu_groups/5/devices/0000:00:16.0 /sys/kernel/iommu_groups/13/devices/0000:03:00.0 /sys/kernel/iommu_groups/3/devices/0000:00:03.0...

Bonjour, Fisrt of all , it's fresh home lab, so no vm; no critical data. before : root@qc5000:~# zpool status -v pool: rpool state: ONLINE scan: scrub repaired 0B in 0 days 00:00:06 with 0 errors on Fri Oct 2 23:03:48 2020 config: NAME...

Any suggestion for spice client on android ? looks good

i think you can launch a torture test for cpu with prime95 for exemple ( https://www.mersenne.org/download/ ) and in, the meantime you launch in another console this : watch sensors and you will see which temperature is growing very high. Becarefull, prime95 uut the server in is limit...

With mdadm / glusterfs you have a real time synchronisation. take a lot à rsnapshot https://wiki.debian-fr.xyz/Rsnapshot if you choose something like rsync

software raid, rsync or glusterfs ....

Good question . i think you can mount the datastore on another pbs server it needed. Maybe someone can confirm that.

Maybe mount the disk on the PBS server. Create a datastore on it. Create a sync job between the orignal data store and the usb one.

ok

Bonjour, Just to know if it's possible or not. Dark26

i have this option too ( daily both ) Maybe possible to set a différent time between the 2 tasks when the same schedule is set.

I will tell if the problem appears tommorow or if i can reproduce it.

Bonjour, I have this message on the task list : 2020-09-03T00:00:00+02:00: starting garbage collection on store Backup_Day 2020-09-03T00:00:00+02:00: task triggered by schedule 'daily' 2020-09-03T00:00:00+02:00: Start GC phase1 (mark used chunks) 2020-09-03T00:00:09+02:00: TASK ERROR: Unable...

Absolut weird.... the same for me... I did not change anything (no update/no extra reboot/etc) --> same here . after the test twith a backup in a stop mod yesterday, today all is ok on all backup strange Proxmox Virtual Environment 6.2-11 Rechercher Datacenter Rechercher: Vue Serveur...

Much better in stop mode INFO: starting new backup job: vzdump 179 --mode stop --node p2 --storage Backup_Day --remove 0 INFO: Starting Backup of VM 179 (lxc) INFO: Backup started at 2020-09-02 00:13:43 INFO: status = running INFO: backup mode: stop INFO: ionice priority: 7 INFO: CT Name...

One LXC is even worse : 179: 2020-08-25 03:00:03 INFO: Starting Backup of VM 179 (lxc) 179: 2020-08-25 03:00:03 INFO: status = running 179: 2020-08-25 03:00:03 INFO: CT Name: nextcloud 179: 2020-08-25 03:00:03 INFO: including mount point rootfs ('/') in backup 179: 2020-08-25 03:00:03 INFO...

pveversion -v proxmox-ve: 6.2-1 (running kernel: 5.4.55-1-pve) pve-manager: 6.2-11 (running version: 6.2-11/22fb4983) pve-kernel-5.4: 6.2-5 pve-kernel-helper: 6.2-5 pve-kernel-5.4.55-1-pve: 5.4.55-1 pve-kernel-5.4.44-2-pve: 5.4.44-2 ceph: 14.2.10-pve1 ceph-fuse: 14.2.10-pve1 corosync: 3.0.4-pve1...

Same problem here Now after upgrade and reboot INFO: root.pxar: had to upload 1.26 GiB of 2.33 GiB in 213.43s, average speed 6.02 MiB/s). INFO: root.pxar: backup was done incrementally, reused 1.08 GiB (46.2%) INFO: Uploaded backup catalog (1.14 MiB) INFO: root.pxar: had to upload 1.26 GiB of...

maybe try to boot on a live cd and see if there any hardware problem. it's like a hard drive failure, or a cable problem

PBS server in a vm in pve. 1 Go ram 2 vcpu. backend store Store is a disk image on a cifs share on a freebox ( speed max around 25 mo /s) Uploaded 101 chunks in 5 seconds. Time per request: 52430 microseconds. TLS speed: 80.00 MB/s SHA256 speed: 107.57 MB/s Compression speed: 295.80 MB/s...