NVP-vProxy: Backups schlagen mit "Panic occurred runtime error" fehl, wenn data01 voll ist

VM-Backups schlagen auf einer bestimmten vProxy-Appliance zeitweise fehl. Das NetWorker-Workflowprotokoll zeigt einen 500-Fehler mit einer Panic-Laufzeitmeldung an:

MM/DD/YYYY HH:MM:SS [VM_NAME]: Unable to start backup on vProxy '[VPROXY_NAME]': Received an HTTP code: 500, libCURL message: "", vProxy message: "Error received from vProxy ="-500: Panic occurred: runtime error: invalid memory address or nil pointer dereference". ", url: "https://[VPROXY_NAME]:9090/api/v1/BackupVmSessions", body: "{"Config":{"SessionId":"","LogTag":"@(#) Build number: 288","IdleTimeout":300,"LogLevel":"TRACE","AcceptedLanguage":"en","TransportModeRequested":"hotadd","Parallelism":1,"UseCbt":true,"AutoEnableCbt":true,"AutoRepairCbt":true,"VimServerRef":{"HostName":"[VCENTER_NAME]","UserName":"S001891","UserPassword":"****","TcpPort":0},"VmSpec":{"Name":"[VM_NAME]","VmMoref":"vm-152712","VirtualDisks":[{"Label":"Hard disk 1","Key":2000}],"CustomFieldName":"Last EMC vProxy Backup","CustomFieldValue":"Backup Server=[NSR_NAME], Policy=[POLICY_NAME], Workflow=[WORKFLOW_NAME], Action=[ACTION_NAME], JobId=490597"},"SnapshotSpec":{"Name":"NetWorker Backup Snapshot","Description":"Snapshot is created as part of protecting this VM by EMC NetWorker VProxy.","Quiesce":false,"DumpMemory":false,"RemoveAll":false,"Consolidate":false},"TargetSpec":{"DeviceType":"DataDomain","HostName":"[DATADOMAIN_NAME]","UserName":"boostadmin","UserPassword":"****","BackupMode":"VSS","BackupPath":"[NSR_NAME]/[DEVICE_NAME]//[NSR_NAME]/[DEVICE_NAME]/05/47/e03a0faf-00000006-9122ca5e-5b22ca5e-5380e9f4-822ca7d4","PreviousBackupPath":"/[NSR_NAME]/[DEVICE_NAME]/75/82/7f12c16b-00000006-2720fcc2-5b20fcc2-40eae9f4-822ca7d4","CurrentBackupPath":"/[NSR_NAME]/[DEVICE_NAME]/active/e03a0faf-00000006-9122ca5e-5b22ca5e-5380e9f4-822ca7d4"}}}".

Die Tasten /data01 Das Dateisystem auf der vProxy-Appliance zeigt eine Auslastung von 100 % an:

myvproxy:/data01/runtime/logs # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 17G 2.7G 14G 18% /
devtmpfs 3.9G 8.0K 3.9G 1% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 8.8M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda4 17G 2.7G 14G 18% /.snapshots
/dev/sda4 17G 2.7G 14G 18% /var/crash
/dev/sda4 17G 2.7G 14G 18% /var/tmp
/dev/sda4 17G 2.7G 14G 18% /usr/local
/dev/sda4 17G 2.7G 14G 18% /var/spool
/dev/sda4 17G 2.7G 14G 18% /var/lib/pgsql
/dev/sda4 17G 2.7G 14G 18% /var/opt
/dev/sda4 17G 2.7G 14G 18% /var/lib/mailman
/dev/sda4 17G 2.7G 14G 18% /var/lib/named
/dev/sda4 17G 2.7G 14G 18% /srv
/dev/sda4 17G 2.7G 14G 18% /opt
/dev/sda4 17G 2.7G 14G 18% /home
/dev/sda4 17G 2.7G 14G 18% /tmp
/dev/sda4 17G 2.7G 14G 18% /var/log
/dev/sdb1 82G 82G 20K 100% /data01
/dev/sda2 95M 73M 18M 81% /boot
/dev/sda4 17G 2.7G 14G 18% /boot/grub2/x86_64-efi
/dev/sda4 17G 2.7G 14G 18% /boot/grub2/i386-pc
/dev/sdb2 16G 33M 16G 1% /data01/logs

Der Speicherplatz wird von Backupsitzungsprotokollen in /opt/emc/vproxy/runtime/logs/. Diese Protokolle befinden sich auf der /data01 Partition befanden. Andere VMs auf verschiedenen vProxy-Appliances werden weiterhin erfolgreich gesichert.

Die Tasten /data01 Dateisystem auf der vProxy-Appliance speichert Backupsitzungsprotokolle in /opt/emc/vproxy/runtime/. Die standardmäßige Protokollaufbewahrung beträgt einen Monat. In Umgebungen mit hoher Backupaktivität können die Sitzungsprotokolle den gesamten verfügbaren Speicherplatz auf /data01.

Wenn die Partition 100 % erreicht, kann der vProxy keine neuen Sitzungsprotokolldateien erstellen. Der Backupprozess erkennt eine Nullzeiger-Dereferenzierung, wenn das Protokoll nicht geschrieben werden kann. Dies löst einen Panic-Laufzeitfehler mit dem HTTP-Statuscode 500 aus.

Option 1 – Erneutes Bereitstellen der vProxy-Appliance

Stellen Sie die vProxy-Appliance über die PPDM- oder NetWorker-Konsole erneut bereit. Bei der erneuten Bereitstellung werden alle vorhandenen Protokolle gelöscht und die /data01 Partition befanden.

Option 2 – Manuelle Rückgewinnung von Speicherplatz

Wenn eine erneute Bereitstellung nicht sofort möglich ist:

1. Melden Sie sich über SSH beim vProxy an als admin. Wechseln zu root:

   sudo su - root

2. Löschen Sie alte wiederverwertete Sitzungsprotokolle, um Speicherplatz wiederzugewinnen:

   find /opt/emc/vproxy/runtime/logs/recycle/ -type f -mtime +14 -delete

3. Überprüfen Sie, ob Speicherplatz zurückgewonnen wurde:

   df -h /data01

4. Wiederholen Sie das Backup für die betroffenen VMs.

Prevent recurrence: Konfigurieren Sie einen Cronjob zur Protokollbereinigung

Um zu verhindern, dass /data01 wieder 100 % erreicht, erstellen Sie einen geplanten Bereinigungsjob:

1. Melden Sie sich über SSH beim vProxy an als admin. Wechseln zu root:

   sudo su - root

2. Erstellen Sie einen Crontab-Eintrag für die root Benutzer:

   crontab -e

3. Fügen Sie die folgende Zeile hinzu, um jeden Tag um 6 Uhr morgens Sitzungsprotokolle zu löschen, die älter als 14 Tage sind:

   0 6 * * * find /opt/emc/vproxy/runtime/logs/recycle/vbackupd -type f -mtime +14 -delete

4. Speichern und schließen Sie die Datei. Überprüfen Sie . cron Jobs

   crontab -l

Wenden Sie sich an den Dell Support.

Wenn die /data01 Füllt sich nach der Implementierung der Bereinigung weiterhin schnell. Wenden Sie sich für weitere Untersuchungen an den Dell Support . Siehe Wissensdatenbank-Artikel:

Speicherplatz auf dem Einhängepunkt /data01 des vProxy kann zurückgewonnen werden, indem Protokolle aus gelöscht werden: /data01/runtime/logs/recycle/

Hier ist ein Beispielverfahren zum Erstellen eines Cronjobs, der die 14 Tage alten Protokolle löscht:

• Melden Sie sich über SSH als Administrator beim vProxy an und wechseln Sie dann zu root: sudo su - root
• Erstellen Sie einen Crontab-Job für den Root-Nutzer mit: crontab -e
• Fügen Sie im Texteditor die folgende Zeile ein, um die Sitzungsprotokolle, die älter als 14 Tage sind, jeden Tag um 6:00 Uhr zu löschen:

* 6 * * * find /opt/emc/vproxy/runtime/logs/recycle/vbackupd -type f -mtime +14 -delete

• Zeigen Sie den Inhalt des neuen Root-Nutzer-Cronjobs mit folgendem Befehl an: crontab -l
• Die Anzahl der Tage für die Aufbewahrung von Protokollen kann geändert werden, um zu verhindern, dass das Dateisystem 100 % erreicht.