Backup errors
- Thread starter Erwin123
- Start date
Well, maybe your machine is just too slow (1.4MiB/s). You can try to increase snapshot size again, but I would simply go for the new machine (or use 'stop' mode).
I'll transfer both containers to the new node tomorrow morning.
I'll also increase the backupsize in the hope they work tonight, because its a nice feeling if you have a backup before you begin a migration
.
btw what does the 'size' parameter exactly specifies?
I'll also increase the backupsize in the hope they work tonight, because its a nice feeling if you have a backup before you begin a migration
.btw what does the 'size' parameter exactly specifies?
First, try a larger snapshot size for /etc/vzdump.conf
Second, what are you using for your I/O scheduler? I bet you're using the default one which performs incredibly poorly for me.
See which scheduler you're currently using:
cat /sys/block/sda/queue/scheduler
Try deadline, it works well for me:
/bin/echo "deadline" > /sys/block/sda/queue/scheduler
Code:
size: 3072See which scheduler you're currently using:
cat /sys/block/sda/queue/scheduler
Try deadline, it works well for me:
/bin/echo "deadline" > /sys/block/sda/queue/scheduler
Today I got the same error here - I will try to debug it.
But the slow speed is really strange. Try the 'deadline' scheduler as suggested by tog.
You are/were using cfq, it was indicating that by surrounding it with square brackets.
No, you don't have to restart, the change takes immediate effect. Your I/O scheduler is changed to deadline as soon as you do that echo command.
If it works out for you and you'd like to make it permanent, put that echo command in /etc/rc.local
No, you don't have to restart, the change takes immediate effect. Your I/O scheduler is changed to deadline as soon as you do that echo command.
If it works out for you and you'd like to make it permanent, put that echo command in /etc/rc.local
I have no idea, I hope you can tell me
edit: I've tried pveperf a few times in a row, mostly the seektime is between 8 and 13 ms...
what hard drives do you use, model number?
Seek times between 8-20ms using 7200RPM SATA drives is fine and normal. If you really required a fast disk subsystem for an I/O-heavy workload you'd have to get some 10k RPM Raptors or use 15k RPM SAS or SCSI drives or use a SAN.
To be honest if my 7200RPM disk mirror ever became consistently overwhelmed with my workload I'd probably just put up a Solaris server using ZFS and use it as an iSCSI target rather than throw expensive hardware RAID stuff at Linux. I just love when one disk in a hardware RAID goes bad and overwrites your good copy of the data with bad data, really makes me enthusiastic about buying more $400-$600 hardware RAID controllers in the future.
For most typical workloads, normal 7200RPM drives are fine. Slower than 5MB/s backups is quite abnormal, hopefully changing your scheduler from cfq helped with that issue.
If you have a gigabit LAN you should do as the Proxmox guys suggest and stream your vzdumps to another server over an SMB or NFS mount.
To be honest if my 7200RPM disk mirror ever became consistently overwhelmed with my workload I'd probably just put up a Solaris server using ZFS and use it as an iSCSI target rather than throw expensive hardware RAID stuff at Linux. I just love when one disk in a hardware RAID goes bad and overwrites your good copy of the data with bad data, really makes me enthusiastic about buying more $400-$600 hardware RAID controllers in the future.
For most typical workloads, normal 7200RPM drives are fine. Slower than 5MB/s backups is quite abnormal, hopefully changing your scheduler from cfq helped with that issue.
If you have a gigabit LAN you should do as the Proxmox guys suggest and stream your vzdumps to another server over an SMB or NFS mount.
I've changed the servers to the new io scheduler.
This is the log from tonight on the 2 disk raid-1 server:
I took a look at my snapshot archive, the same server on 30 september had 5.3MiB/s but with far less sites (the backup was 5GB).
This is the server with 8 sata disks in raid-10 tonight:
I've bought this server with the idea of hosting at least 20 customers vps's. Now it appears to be full with one 20GB container with low traffic websites (total of 75 or 85 GB a month).
It seems I have a problem
This is the log from tonight on the 2 disk raid-1 server:
I took a look at my snapshot archive, the same server on 30 september had 5.3MiB/s but with far less sites (the backup was 5GB).
This is the server with 8 sata disks in raid-10 tonight:
I've bought this server with the idea of hosting at least 20 customers vps's. Now it appears to be full with one 20GB container with low traffic websites (total of 75 or 85 GB a month).
It seems I have a problem
Last edited:
My only guess at this point about why your backups are slow is that you have a heavy I/O workload during the backup process. An 8-disk RAID-10 shouldn't be that slow to do backups. Maybe you don't have write caching on and your writes are really slow even though your reads are fast?
If you could maybe use an SMB or NFS mount to another server and do the vzdumps to that, that would probably help make it go faster.
I don't understand what exactly you mean by your server is full with one 20GB container. You mean your disk I/O capabilities are utilized or your free disk space is all utilized or what?
If your disks are being beaten on that much you may need to consider one of my earlier suggestions about getting a faster I/O subsystem setup. You could throw faster 10k RPM Raptor drives at the problem (using the existing SATA RAID controller) or setup a fast NAS server to place your containers on.
If you could maybe use an SMB or NFS mount to another server and do the vzdumps to that, that would probably help make it go faster.
I don't understand what exactly you mean by your server is full with one 20GB container. You mean your disk I/O capabilities are utilized or your free disk space is all utilized or what?
If your disks are being beaten on that much you may need to consider one of my earlier suggestions about getting a faster I/O subsystem setup. You could throw faster 10k RPM Raptor drives at the problem (using the existing SATA RAID controller) or setup a fast NAS server to place your containers on.