Search results

the test was to backup (snapshot mode with no compression) the same 5 productive VMs from the same 3 productive proxmox servers (described in the first post at the top) on to 5 different NFS-devices/servers an error is for me a message like this in the syslog while a backup Jun 14 19:16:04 pve02...

i used no compression (because i try to avoid an additional error variable at restoring) and snapshot, as these two are also my productive settings Windows Storage Server could be interesting too, you're right please keep me up i hope the proxmox guys see my offer :)

in the last few days i did again a few tests, the first test scenario was to install a few nas-distributions on the same server and test it server as mentioned in the first post: Dell Poweredge 2950, Xeon 5130, 4GB RAM, 4x 146GB 15k SAS in every testrun i tried to backup 5 VMs 101 (17,5GiB)...

maybe the kernel panic was triggered by the leap second in the last days i've read some reports that linux had problems with that

i had this problems with hung up backups and lost connections to mounted nfs shares

yes, that would be great but there is still the question why there are problems with buffalo and qnap nas, and why the problem is only on pve2.x and not on 1.9 (and earlier) to be honest i'm a little bit disappointed of the pve team that the fault is deported so easily

i will do that export - reinstall - import thing later the next two days i have holiday, so i will report as soon as possible maybe the proxmox team has another hints why 2 of 3 pve server doesn't like this freenas server

not yet but thats also something i think about to do particularly it would be done very fast and without much work (just some downtime of the nas) the big backup just got ready Jun 27 15:45:52 INFO: Starting Backup of VM 202 (qemu) Jun 27 15:45:52 INFO: status = running Jun 27 15:45:53 INFO...

the productive nas01 server has about 8,2 TB storage (5x3TB raidz2) and currently between 3 and 6 TB are free (i deleted the last days a lot of old backups from it) there is no compression active and completely default settings from freenas on the test-nas02/pve04 server i've setup a illumian...

yesterday afternoon i made from the test-pve04 server another freenas server with 8.0.4.p3 as of the disk-space there is limited i tried it there with lzo compression and the first backups went quite good with very low error output with time and increasing VMs backuped/decreasing space on the...

gz ewuweu that your problem could be solved :) maybe some of you guys have another solution-idea for Erk and me @tom or dietmar: do you have any clou why there is this difference between 1.9 and 2.x?

in the meantime i tried a lot of things, even the directory storage with tcp mounted nfs storage hasnt changed anything but i have upgraded the TEST-pve04 server with pve 1.9 to pve2.1 and yes, what should i say, here is it again: Jun 26 10:29:14 pve04 pvestatd[1549]: WARNING: command 'df -P -B...

Unfortunately, the backup process hangs at ~9GB again (i haven't done a reboot of freenas, but i don' think this is necessary) next thing i try is: start a backup on pve01 and wait till it hangs and than immediately start another backup on pve02 and lets see how the speed is from pve02 is edit...

no, asynchronous is not activated i mounted it with this mount 192.168.1.1:/mnt/DATA/pve /mnt/pve/pve2 -o rsize=8192,wsize=8192,nolock,timeo=14,intr,proto=tcp,port=2049 now i did a dd-test with "time dd if=/dev/zero of=/mnt/pve/pve2/bigfile03.txt bs=32k count=640000" and now i'm getting the...

@dietmar: when restoring i have super fast speeds with about 80mb/s and more @RobFantini: thanks for the info with "number of servers". to be sure i raised this from 4 to 16 but there was/is no positive change and as i said, in the log are no errors regarding this issue (only ARP changes of two...

vmbr0 should be your management lan with an assigned ip when you create vmbr1 with eth1 just assign no ip and you have what you want

no, unfortunately not, that would be too nice and easy :( "good" to hear that i'm not alone with this problem this are my dd test results root@pve01:~# time dd if=/dev/zero of=/mnt/pve/pve01/bigfile01.txt bs=8k count=256000 256000+0 records in 256000+0 records out 2097152000 bytes (2.1 GB)...

i have tested it now with size of 2000, 4000, 8000 and 16000 i will post the results from the first run (4000) cause all others are quite the same in the first ~2 minutes about 8gb are written and lvdisplay looks like this --- Logical volume --- LV Path /dev/pve/vzsnap-pve02-0...

this was a backup on pve02 with PVE1.9 May 25 23:02:42 INFO: Starting Backup of VM 203 (qemu) May 25 23:02:42 INFO: running May 25 23:02:42 INFO: status = running May 25 23:02:42 INFO: backup mode: snapshot May 25 23:02:42 INFO: ionice priority: 7 May 25 23:02:43 INFO: Logical volume...

Hi, since i upgraded from PVE 1.9 to PVE 2.x i have on 2 of my 3 systems big problems with the backup-speed. All 3 are in a cluster-configuration but only for simple administration. Every VM is on the local storage and so on. This are the three systems: PVE01: Dell R710, 2x Xeon E5520, 24GB...