[SOLVED] Backup sehr langsam

S

ShaneDeak

Member
Nov 18, 2019
14
0
21
44
Hallo zusammen,

ich habe seit einigen Wochen das Problem, dass mein Backup auf einem meiner PVEs extrem langsam ist. Gesichert wird auf ein NFS-Storage. Ein zweiter PVE sichert dort ebenfalls hin, mit einwandfreier Geschwindigkeit.

Vorletzte Woche habe ich eine defekte Platte meines Raid-1 ausgetauscht und dachte, dass es damit dann behoben sein müsste. Leider ist dem nicht so. Außer der getauschten Platte hat sich aber nichts am System geändert in den letzten Wochen.

Hier das aktuelle Backup, gestartet gestern Abend um 20 Uhr:

Code: 
()
INFO: starting new backup job: vzdump 120 122 123 124 160 161 --mode snapshot --quiet 1 --storage daily_backups --mailnotification always --compress lzo --mailto xxx
INFO: skip external VMs: 160, 161
INFO: Starting Backup of VM 120 (qemu)
INFO: status = running
INFO: update VM 120: -lock backup
INFO: VM Name: win2011
INFO: include disk 'ide0' 'local-lvm:vm-120-disk-1' 1050G
INFO: include disk 'ide3' 'local-lvm:vm-120-disk-2' 200G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/daily_backups/dump/vzdump-qemu-120-2019_12_04-20_00_02.vma.lzo'
INFO: started backup task '4c9ebd80-098f-4f1c-8a69-f03526d15362'
INFO: status: 0% (196345856/1342177280000), sparse 0% (33931264), duration 3, read/write 65/54 MB/s
INFO: status: 1% (13433831424/1342177280000), sparse 0% (185823232), duration 729, read/write 18/18 MB/s
INFO: status: 2% (26848854016/1342177280000), sparse 0% (361201664), duration 1738, read/write 13/13 MB/s
INFO: status: 3% (40280129536/1342177280000), sparse 0% (949530624), duration 2428, read/write 19/18 MB/s
INFO: status: 4% (53696069632/1342177280000), sparse 0% (1135845376), duration 3327, read/write 14/14 MB/s
INFO: status: 5% (67112206336/1342177280000), sparse 0% (1439039488), duration 4010, read/write 19/19 MB/s
INFO: status: 6% (80536469504/1342177280000), sparse 0% (1600368640), duration 5031, read/write 13/12 MB/s
INFO: status: 7% (93953261568/1342177280000), sparse 0% (1884155904), duration 5907, read/write 15/14 MB/s
INFO: status: 8% (107389779968/1342177280000), sparse 0% (2046566400), duration 6850, read/write 14/14 MB/s
INFO: status: 9% (120807555072/1342177280000), sparse 0% (2101460992), duration 7587, read/write 18/18 MB/s
INFO: status: 10% (134231621632/1342177280000), sparse 0% (2144813056), duration 8732, read/write 11/11 MB/s
INFO: status: 11% (147643891712/1342177280000), sparse 0% (2203492352), duration 9704, read/write 13/13 MB/s
INFO: status: 12% (161065467904/1342177280000), sparse 0% (2229100544), duration 10821, read/write 12/11 MB/s
INFO: status: 13% (174485143552/1342177280000), sparse 0% (2236334080), duration 11687, read/write 15/15 MB/s
INFO: status: 14% (187909865472/1342177280000), sparse 0% (2247147520), duration 12297, read/write 22/21 MB/s
INFO: status: 15% (201347432448/1342177280000), sparse 0% (2256773120), duration 13208, read/write 14/14 MB/s
INFO: status: 16% (214750199808/1342177280000), sparse 0% (2290331648), duration 13981, read/write 17/17 MB/s
INFO: status: 17% (228176887808/1342177280000), sparse 0% (2317639680), duration 14825, read/write 15/15 MB/s
INFO: status: 18% (241597677568/1342177280000), sparse 0% (2499219456), duration 15444, read/write 21/21 MB/s
INFO: status: 19% (255018795008/1342177280000), sparse 0% (2528186368), duration 16137, read/write 19/19 MB/s
INFO: status: 20% (268446269440/1342177280000), sparse 0% (2555506688), duration 16980, read/write 15/15 MB/s


Und hier noch das Backup vom 08.11., als es noch schnell lief:


Code: 
vzdump 120 122 123 124 160 161 --compress lzo --mailnotification always --quiet 1 --storage daily_backups --mailto xxx --mode snapshot


120: 2019-11-07 20:00:03 INFO: Starting Backup of VM 120 (qemu)
120: 2019-11-07 20:00:03 INFO: status = running
120: 2019-11-07 20:00:04 INFO: update VM 120: -lock backup
120: 2019-11-07 20:00:04 INFO: VM Name: win2011
120: 2019-11-07 20:00:04 INFO: include disk 'ide0' 'local-lvm:vm-120-disk-1' 1050G
120: 2019-11-07 20:00:04 INFO: include disk 'ide3' 'local-lvm:vm-120-disk-2' 200G
120: 2019-11-07 20:00:04 INFO: backup mode: snapshot
120: 2019-11-07 20:00:04 INFO: ionice priority: 7
120: 2019-11-07 20:00:04 INFO: creating archive '/mnt/pve/daily_backups/dump/vzdump-qemu-120-2019_11_07-20_00_03.vma.lzo'
120: 2019-11-07 20:00:04 INFO: started backup task 'e6d4df44-995e-4515-be31-6727dbacf349'
120: 2019-11-07 20:00:07 INFO: status: 0% (182845440/1342177280000), sparse 0% (33808384), duration 3, read/write 60/49 MB/s
120: 2019-11-07 20:06:32 INFO: status: 1% (13473480704/1342177280000), sparse 0% (177311744), duration 388, read/write 34/34 MB/s
120: 2019-11-07 20:11:13 INFO: status: 2% (26872315904/1342177280000), sparse 0% (353337344), duration 669, read/write 47/47 MB/s
120: 2019-11-07 20:15:40 INFO: status: 3% (40284717056/1342177280000), sparse 0% (1046335488), duration 936, read/write 50/47 MB/s
120: 2019-11-07 20:20:04 INFO: status: 4% (53698297856/1342177280000), sparse 0% (1200689152), duration 1200, read/write 50/50 MB/s
120: 2019-11-07 20:24:06 INFO: status: 5% (67127214080/1342177280000), sparse 0% (1518698496), duration 1442, read/write 55/54 MB/s
120: 2019-11-07 20:30:36 INFO: status: 6% (80531685376/1342177280000), sparse 0% (1680797696), duration 1832, read/write 34/33 MB/s
120: 2019-11-07 20:36:50 INFO: status: 7% (93964664832/1342177280000), sparse 0% (1946497024), duration 2206, read/write 35/35 MB/s
120: 2019-11-07 20:41:16 INFO: status: 8% (107457675264/1342177280000), sparse 0% (2099556352), duration 2472, read/write 50/50 MB/s
120: 2019-11-07 20:44:59 INFO: status: 9% (120849039360/1342177280000), sparse 0% (2157957120), duration 2695, read/write 60/59 MB/s
120: 2019-11-07 20:48:26 INFO: status: 10% (134265831424/1342177280000), sparse 0% (2197569536), duration 2902, read/write 64/64 MB/s
120: 2019-11-07 20:51:54 INFO: status: 11% (147713556480/1342177280000), sparse 0% (2257334272), duration 3110, read/write 64/64 MB/s
120: 2019-11-07 20:54:57 INFO: status: 12% (161154727936/1342177280000), sparse 0% (2284064768), duration 3293, read/write 73/73 MB/s
120: 2019-11-07 20:57:43 INFO: status: 13% (174568046592/1342177280000), sparse 0% (2291466240), duration 3459, read/write 80/80 MB/s
120: 2019-11-07 21:00:21 INFO: status: 14% (187909668864/1342177280000), sparse 0% (2302210048), duration 3617, read/write 84/84 MB/s
120: 2019-11-07 21:03:03 INFO: status: 15% (201349660672/1342177280000), sparse 0% (2310369280), duration 3779, read/write 82/82 MB/s
120: 2019-11-07 21:05:47 INFO: status: 16% (214818488320/1342177280000), sparse 0% (2344927232), duration 3943, read/write 82/81 MB/s
120: 2019-11-07 21:08:32 INFO: status: 17% (228200742912/1342177280000), sparse 0% (2367168512), duration 4108, read/write 81/80 MB/s
120: 2019-11-07 21:12:27 INFO: status: 18% (241637130240/1342177280000), sparse 0% (2552180736), duration 4343, read/write 57/56 MB/s
120: 2019-11-07 21:16:38 INFO: status: 19% (255036293120/1342177280000), sparse 0% (2581553152), duration 4594, read/write 53/53 MB/s
120: 2019-11-07 21:20:33 INFO: status: 20% (268486443008/1342177280000), sparse 0% (2608644096), duration 4829, read/write 57/57 MB/s
.
.
.
120: 2019-11-08 02:09:52 INFO: status: 99% (1329187454976/1342177280000), sparse 11% (159152984064), duration 22188, read/write 804/0 MB/s
120: 2019-11-08 02:10:08 INFO: status: 100% (1342177280000/1342177280000), sparse 12% (172142809088), duration 22204, read/write 811/0 MB/s
120: 2019-11-08 02:10:08 INFO: transferred 1342177 MB in 22204 seconds (60 MB/s)
120: 2019-11-08 02:10:08 INFO: archive file size: 595.42GB
120: 2019-11-08 02:10:08 INFO: delete old backup '/mnt/pve/daily_backups/dump/vzdump-qemu-120-2019_11_05-20_00_04.vma.lzo'
120: 2019-11-08 02:10:14 INFO: Finished Backup of VM 120 (06:10:11)

Verzweifelte Grüße und besten Dank im Voraus!
 
Kurze Ergänzung: Es kann auch nicht an der Windows-VM (VM 120) liegen.
Eine andere Windows-VM ist auch nur halb so schnell:
Aktuell: INFO: transferred 103079 MB in 3842 seconds (26 MB/s)
08.11.: INFO: transferred 103079 MB in 1766 seconds (58 MB/s)
 
Dann gleich mal die obligatorische Frage: Was hast du in den letzten Wochen geändert? Welche PVE-Version ist das jetzt?
 
Hi,

Kannst du bitte mal testen ob die Geschwindigkeit auch schlecht ist wenn du auf ein lokale FS Backups?
 
wolfgang said:
Hi,

Kannst du bitte mal testen ob die Geschwindigkeit auch schlecht ist wenn du auf ein lokale FS Backups?
Click to expand...

Leider habe ich lokal nur ein LVM-thin, daher konnte ich nur mit einer USB-Festplatte testen. Auch hier ist das Backup nicht schneller.

Der IO-Delay ist während des Backups zeitweise sehr hoch:
IO-Delay.PNG

Das Backup lief am Wochenende mit 35 MB/s (1189,79 GB in 17 Stunden 22 Minuten). Es ist wohl zu befürchten, dass es ein Hardware-Problem ist, aber falls jemand noch eine Idee hat, wäre ich sehr dankbar!

Ich habe am Wochenende ein Upgrade auf Proxmox VE 5.4-13 gemacht.
 
Was mir aufgefallen ist du verwendest ide als vdisk bus.
Kannst du das auf scsi mit vitio umstellen?
IDE ist generell langsam und auch nicht empfohlen.
 
wolfgang said:
Was mir aufgefallen ist du verwendest ide als vdisk bus.
Kannst du das auf scsi mit vitio umstellen?
IDE ist generell langsam und auch nicht empfohlen.
Click to expand...

Bei den beiden großen Windows-VMs ist das sehr aufwändig. Ich habe es aber bei ner Kleineren gemacht und vorher und danach ein Backup erstellt. Im Schnitt waren es jeweils um 35 MB/s. Es gab also keine Verbesserung der Backup-Geschwindigkeit.
Zum Vergleich: Auf meinem zweiten PVE läuft eine sehr ähnliche Windows-2016-VM, bei der die Sicherung im Schnitt mit 202 MB/s läuft.

Dennoch natürlich vielen Dank für den Hinweis! Ich werde noch bei allen VMs auf SCSI umstellen.
 
Kann das sein das dein LVM durch neue VM einfach nicht mehr schnell genug ist?
Super wäre ein Benchmark von host auf dem LVM um zu sehen wie schnell das Storage generell ist.
 
Windows Server 2011 auf PVE1 (mit IDE-Platten):
CrystalDiskMark_Win2011.png

Windows Server 2016 auf PVE1 (mit SCSI-Platte):
CrystalDiskMark_Win2016.1.png

Windows Server 2016 auf PVE2 (mit SCSI-Platte):
CrystalDiskMark_Win2016.2.png
 
Habe noch auf nem Windows 2012 R2, der auch auf dem PVE1 liegt, nen Benchmark laufen lassen und hier jetzt dieses überraschende Ergebnis:

CrystalDiskMark_Win2012.png

Beim Backup ist der aber auch nicht schneller.
 
Hallo nochmals!
Inzwischen habe ich den Verdacht, dass noch eine Platte ne Macke hat.
Ich würde nun gerne per smartctl die einzelnen Platten überprüfen. Leider klappt das nicht, da ich nicht die richtige Abfrage in Verbindung mit nem LVM thin hin bekommen.
Kann mir da jemand helfen?
 
ShaneDeak said:
Hallo nochmals!
Inzwischen habe ich den Verdacht, dass noch eine Platte ne Macke hat.
Ich würde nun gerne per smartctl die einzelnen Platten überprüfen. Leider klappt das nicht, da ich nicht die richtige Abfrage in Verbindung mit nem LVM thin hin bekommen.
Kann mir da jemand helfen?
Click to expand...

Habe es doch noch selber rausgefunden:

Code: 
root@pve1:/# smartctl -l xerror -d sat+megaraid,11 /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.18-23-pve] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Extended Comprehensive Error Log Version: 1 (6 sectors)
Device Error Count: 7766 (device log contains only the most recent 24 errors)
        CR     = Command Register
        FEATR  = Features Register
        COUNT  = Count (was: Sector Count) Register
        LBA_48 = Upper bytes of LBA High/Mid/Low Registers ]  ATA-8
        LH     = LBA High (was: Cylinder High) Register    ]   LBA
        LM     = LBA Mid (was: Cylinder Low) Register      ] Register
        LL     = LBA Low (was: Sector Number) Register     ]
        DV     = Device (was: Device/Head) Register
        DC     = Device Control Register
        ER     = Error register
        ST     = Status register
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 7766 [13] occurred at disk power-on lifetime: 18604 hours (775 days + 4 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 00 00 00 16 d1 b2 59 40 00  Error: WP at LBA = 0x16d1b259 = 382841433

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  61 00 28 00 10 00 00 4c 5c 88 b8 40 00  1d+07:34:23.993  WRITE FPDMA QUEUED
  61 00 08 00 08 00 00 06 85 32 98 40 00  1d+07:34:23.993  WRITE FPDMA QUEUED
  60 00 80 00 00 00 00 16 d1 b2 00 40 00  1d+07:34:23.993  READ FPDMA QUEUED
  61 00 10 00 00 00 00 4d 72 df f0 40 00  1d+07:34:23.974  WRITE FPDMA QUEUED
  60 00 59 00 00 00 00 16 d1 b2 00 40 00  1d+07:34:23.952  READ FPDMA QUEUED


Ein Smart-Alert wird aber nicht ausgelöst. Ich werde die Platte am Wochenende mal tauschen.
 
Es lag tatsächlich an der Platte. Zwei Platten waren defekt, aber nur bei einer wurde ein SMART-Alert ausgelöst.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back