Fragensteller
DPM Online Recovery Point creation gets stuck with few MB

Frage
-
Dear community,
we have a strange issue on our hand and I have no more ideas on how to fix this. Maybe someone here can help.
Our company has 4 sites. All the same domain but ~3 weeks ago every site's DPM backups have started regularly failing the online restore point creation for a few servers. This literally is only for a few, yet always the same virtual machines. When the job starts, it begins to count up the processed MB but stops after a while. No matter how often I make consistency checks or start over, it always gets stuck and always on a different amount of MB.
I thought maybe it is a display error at first or it slows down immensly after a while but not, it just gets completely stuck. Even after leaving the job open for 160 hours, not a single MB has changed:
The servers to be backed up that are failing are always the same and always only the same drive on these servers. Local recovery point creation is not affected.
Our setup is as follows:
- Hyper-V-Hosts (clustered on one site, the athers are standalone), Server 2016
- DPM 2016 on Windows 2016 physically (yes on fast Server hardware)
- 10GBbit Network internally 100MBit synchronous DSL
- Always latest patchlevel
- Always latest DPM agent
- Defender-Settings on DPM set to best practices (see here)
- Windows Firewall on DPM set to best practices
What I have tried to fix this:
- Restarted everything
- Did consistency checks
- Double-ckecked AV and Firewall settings (disabled both even for testing puroses)
- did a checkdisk on the affected drives
- deleted (locally and on Azure) and recreated the protection for the affected drive
- deleted (locally and on Azure) the protection for the affected server completely and recreated it in a new Protection group
- disabled VMQ for testing even though we have Intel NICs (see here)
Still, this error repeats itself. It is as if something is stuck in Azure. While these few machines fail, others are running smoothly for weeks doing syncs, backup locally and to Azure.
Does anyone have any more idea on how to approach this issue? I am still a bit new to DPM, I inherited it all from a former admin and so far it ran smooth until this started.
Any help is appreciated.
...ich bin der Jäger des Mondes, bis der Morgen erwacht!
- Bearbeitet Niwo Sapphire Montag, 1. März 2021 10:10
Alle Antworten
-
...ich bin der Jäger des Mondes, bis der Morgen erwacht!
- Bearbeitet Niwo Sapphire Montag, 1. März 2021 13:14
-
Hallo Niwo,
die von dir geschilderten Probleme kann ich bestätigen. Dieses Phänomen beobachte ich allerdings nicht erst seit 3 Wochen. In meinem Fall handelt es sich um zwei Microsoft Azure Backup Server (quasi DPM 2019) bei zwei unserer Kunden.
Hier tritt das Problem verstärkt dann auf, wenn der DPM-Agent innerhalb einer VM installiert ist und nicht die komplette VM (sondern auf Dateiebene) gesichert wird: Das Online-Backup läuft an und lädt relativ schnell ein paar Hundert MB oder sogar GB hoch und kommt dann zum Stillstand. Im Resource Monitor kann man sehen, dass die cbengine.exe zwar noch Daten zu Azure hochlädt, allerdings nur mit wenigen Bytes/s. Zeitweise sieht man die cbengine.exe im lokalen Scratch-Verzeichnis lesen (wahrscheinlich um abzugleichen, was schon hochgeladen wurde und was nicht). Die meiste Zeit sieht es im Resource Monitor allerdings so aus, als ob gar nichts passieren würde.
So stehen die Online-Backupjobs wie von dir beschrieben dann tatsächlich auch mal für mehrere Tage bis der Job dann schließlich (meistens) erfolgreich abgeschlossen wird.Bei der Erstellung von Online Wiederherstellungspunkten einer VM (Sicherung via Agent auf Hyper-V Host) kann ich dieses Phänomen nicht so extrem sehen. Die Performance beim Upload ist zwar auch unterirdisch (7GB in 5,75 Std. bei einer Anbindung von 100Mbit/s symmetrisch) aber das stört bis jetzt nicht wirklich.
Ein Problem in Azure (bspw. Throttling) kann ich mir nicht vorstellen. Ich vermute ein Problem im Zusammenhang mit einem zu langsamen Abgleich des DPMs mit seiner Datenbank, wo geprüft wird, was noch hochzuladen ist und was nicht...
Hoffentlich hat noch jemand eine Idee.
Viele Grüße
Matthias