ESX / ESXi - Hilfethread

Ich hatte es gelöst. Problem war entweder weil ich nicht das neueste Update drauf hatte oder es lag an dem Leerzeichen dass ich im Ordnernamen vorher drin hatte. Nach den beiden Veränderungen ging es dann. Nur bleiben die Platten jetzt ständig Aktive und gehen nicht mehr in den Standby :(
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Guten Tag (mal wieder),

nachdem ich nun das Backup der VM vom ESXi auf eine weitere SSD geschafft habe (mit ausschluss der RDM HDDs), will ich nun das Backup mittels RSync und SSH auf FreeNAS (Test VM auf meinem PC) übertragen.

Der Verbindungsaufbau mittels RSA Key funktioniert, sowie die erste Datenübertragung

Code:
Syncronizing config files
-------------------------------------------------------------------------------
[Filer_SRV08] info: VMX file copied succesfully
[Filer_SRV08] info: VMSD file copied succesfully
[Filer_SRV08] info: VMXF file copied succesfully.
[Filer_SRV08] info: NVRAM file copied succesfully.

Wenn dann allerdings ddie HDDs gesichert werden sollen schaut dass dan so aus.

Code:
Backing up virtual disks...
-------------------------------------------------------------------------------
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08-Snapshot22.vmsn
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-000001.vmdk
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0.vmdk
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/RDM/rdmdisk1-000001.vmdk
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/RDM/rdmdisk1.vmdk
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/RDM/rdmdisk2-000001.vmdk
DISK=/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/RDM/rdmdisk2.vmdk
-------------------------------------------------------------------------------
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08-Snapshot22.vmsn ]
[B][Filer_SRV08] error: /vmfs/volumes/datastore1/xsi-dir/bin/xsibackup-rsync: Exec format error. Binary file not executable.
rsync: connection unexpectedly closed (0 bytes received so far) [sender][/B]
[B]rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0][/B]
Disk [/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-000001.vmdk] excluded
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0.vmdk ]
[B][Filer_SRV08] error: /vmfs/volumes/datastore1/xsi-dir/bin/xsibackup-rsync: Exec format error. Binary file not executable.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0][/B]
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-flat.vmdk ]
[B]/vmfs/volumes/datastore1/xsi-dir/bin/xsibackup-rsync: Exec format error. Binary file not executable.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0][/B]



Wieso steht da im Pfad aufeinmal Datastore1 ? Den habe ich nicht eingetragen bzw im ESXi als Storagenamen vergeben..Das dürfte dann auch der Grund für den Fehler sein..


Dieses Muster kommt bei allen 4 VM.Im Stor des FreeNAS sind auch die erfolgreichen Dateien samt Ordnerstruktur da.

Kann hier einer helfen ?

Gruß
Lucky
 
Zuletzt bearbeitet:
ui - ka. ob bei dem Durcheinander von Fragen die Chancen hoch sind ... aber ich versuchs mal ;-)

Wollte auch meinem ESXi 6, einzelne (AHCI) SATA-HDDs an die gleiche VM durchreichen (genauer: 3). VM ist OMV (Linux). Das Ganze als RDM (hw-komp). Zuerst hat es alles gut funktioniert, aber nach einigen reboots (Kann auch sein - ist im Moment mein Verdacht), nachdem ich APM (idle, spindown) aktiviert habe, hat die VM nach dem Neustart offenbar eine/einzelne HDDs nicht mehr gefunden - also wie wenn die aus wären/nicht reagieren.
Controller ist bei mir Intel Sunpoint wenn ich mich nicht irre (Board: Supermicro X11SSi-LN4F.
 
Code:
Backing up virtual disks...
...
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08-Snapshot22.vmsn ]
[B][Filer_SRV08] error: /vmfs/volumes/datastore1/xsi-dir/bin/xsibackup-rsync: Exec format error. Binary file not executable.
rsync: connection unexpectedly closed (0 bytes received so far) [sender][/B]
[B]rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0][/B]
Disk [/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-000001.vmdk] excluded
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0.vmdk ]
[B][Filer_SRV08] error: /vmfs/volumes/datastore1/xsi-dir/bin/xsibackup-rsync: Exec format error. Binary file not executable.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0][/B]
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-flat.vmdk ]
[B]/vmfs/volumes/datastore1/xsi-dir/bin/xsibackup-rsync: Exec format error. Binary file not executable.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0][/B]
Schau mal in das "xsibackup" Skript. Da steht der Pfad in der Parameterliste drin als xsidefaultpath. Habe ich bei mir einfach angepasst. Also bei mir steht da jetzt
Code:
...
backuproom=0
xsidefaultpath="/vmfs/volumes/data1/xsi-dir"
HOSTNAME=$(hostname -f 2>/dev/null)
...
da das Datenvolume bei mir "data1" heißt.

Du müsstest anstelle von "data1" - bzw. "datastore1" im Default - den Namen deines Volumes eintragen.
 
Habe den Pfad nun angepasst, jetzt bin ich mit neuen Fehlermeldungen konfrontiert.

Code:
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08-Snapshot32.vmsn ]
[Filer_SRV08] error: --server: Command not found.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]
Disk [/vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-000001.vmdk] excluded
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0.vmdk ]
[Filer_SRV08] error: --server: Command not found.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-flat.vmdk ]
--server: Command not found.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]


Der erste Teil der Übertragung (vmx etc.) hat wieder funktioniert.

Das Backup Skript schaut so aus

Code:
/vmfs/volumes/VMII/xsi-dir/xsibackup --backup-prog=rsync --backup-point="192.168.0.115:22:/mnt/Storage/esxi" --backup-type=custom --backup-vms="TV_Management_Linux,PiHole_SRVUBNT,OpenVPN_SRVUBNT,Filer_SRV08!rdmdisk1-000001.vmdk;rdmdisk1.vmdk;rdmdisk2-000001.vmdk;rdmdisk2.vmdk"


Code:
--server: Command not found


Dieser Befehl wird im Skript nicht übergeben noch gibt es ihn als Option laut XSIBackup | VMWare backup software: man Page
...





Ein Rechteproblem seitens FreeNAS kann man ja eigentlich ausschließen - sonst würden ja nicht die Ordner angelegt und die VMX etc Dateien erfolgreich übertragen werden..
 
Zuletzt bearbeitet:
Der erste Teil der Übertragung (vmx etc.) hat wieder funktioniert.
Schön.
Code:
--server: Command not found

Dieser Befehl wird im Skript nicht übergeben noch gibt es ihn als Option laut XSIBackup | VMWare backup software: man Page
...
--server sind interne Schalter.

rsync(1) - Linux man page
"Internal Options

The options --server and --sender are used internally by rsync, and should never be typed by a user under normal circumstances. Some awareness of these options may be needed in certain scenarios, such as when setting up a login that can only run an rsync command. For instance, the support directory of the rsync distribution has an example script named rrsync (for restricted rsync) that can be used with a restricted ssh login."

Ich würde das mal so deuten, dass in einem Aufruf der ganz grob diese Struktur haben sollte "rsync ... <command> --server ..." nur mit "rsync ... --server" aufgerufen wird, also wegen eines fehlenden Kommandos oder Paramters plötzlich der Schalter "--server" als Command interpretiert wird.

Bist du sicher, dass es die Dateien in der Fehlermeldung zum rsync-Zeitpunkt überhaupt gibt? Sind die im Dateisystem vorhanden?

Falls es geht mal aufräumen, also ohne Snapshots. Snapshots konsolidieren.

Von wo nach wo rsyncst Du eigentlich? Von Esx zu Esx?
 
Sorry vorweg das ich hier dazwischen laber habe nur ganz fix 2 Fragen.
Würde mich freuen wenn ich die auch kurz beantwortet bekomme.

Synology NAS, ein verschlüsselter gemeinsamer ordner ist "nur" auf der NAS verschlüsselt und auf dem weg und beim runterladen entschlüsselt?
Gibt es ein Synology Fred wo man sowas besser reinschreiben kann?
 
Bist du sicher, dass es die Dateien in der Fehlermeldung zum rsync-Zeitpunkt überhaupt gibt? Sind die im Dateisystem vorhanden?

Falls es geht mal aufräumen, also ohne Snapshots. Snapshots konsolidieren.

Von wo nach wo rsyncst Du eigentlich? Von Esx zu Esx?

Im Dateisystem sind die aufgezählten Dateien da, hat das Skript ja selbst erstellt (Snapshot), davor habe ich alle Snapshots mal gelöscht.

Auf ein FreeNAS System - zu Testzwecken ist das eine VM auf meinem PC - eigene IP etc.

Hat wieder nicht funktioniert.



Backups auf das interne Storage (andere SSD) funktionieren ohne Problem....es muss also mit dieser Interpretation von --server und rsync zutun haben, nur wie bekomme ich das gefixt ?

Evtl. sollte ich mal ein anderes Ziel OS testen..kan mir aber nicht vorstellen dass ich der Einzige bin, der ESXi VM auf ein FreeNAS sichern will...
 
Zuletzt bearbeitet:
Im Dateisystem sind die aufgezählten Dateien da, hat das Skript ja selbst erstellt (Snapshot), davor habe ich alle Snapshots mal gelöscht.

Auf ein FreeNAS System - zu Testzwecken ist das eine VM auf meinem PC - eigene IP etc.

Hat wieder nicht funktioniert.

Backups auf das interne Storage (andere SSD) funktionieren ohne Problem....es muss also mit dieser Interpretation von --server und rsync zutun haben, nur wie bekomme ich das gefixt ?

Evtl. sollte ich mal ein anderes Ziel OS testen..kan mir aber nicht vorstellen dass ich der Einzige bin, der ESXi VM auf ein FreeNAS sichern will...

Das irritierende ist, dass es bei einigen Dateien - den Haupt VMDKs - funktioniert, bei anderen nicht.

Ein "ls /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0.vmdk" liefert dir genau die Datei zurück? Die gibt es so unter genau dem Pfad?

Es könnte am Zielpfad liegen, wobei dann aber eigentlich gar nichts hätte gesynct werden dürften.

Zur Fehlersuche würde ich einfach mal "zu Fuß" rsyncen.

Also per ssh auf den esx.
In .../xsi-dir/bin wechseln.
Code:
cd /vmfs/volumes/VMII/xsi-dir/bin

Prüfen der ssh-Verbindung: Ein ssh auf den Zielserver mit dem xsibackup_id_rsa key sollte funktionieren. Der public key müsste am Ziel ja schon hinterlegt sein.
Code:
ssh -i ../xsibackup_id_rsa <zieluser>@<freenas-hostname>
Mit exit wieder zurück auf den esx.

Testdatei auf dem esx anlegen.
Code:
touch testfile.txt
und rübersyncen
Code:
./xsibackup-rsync -av -i ../xsibackup_id_rsa testfile.txt <zieluser>@<freenas-hostname>:<zielverzeichnis>

Wenn das keine Fehler auftreten, mit einer Datei die beim Backup nicht ging:
Code:
./xsibackup-rsync -av -i ../xsibackup_id_rsa /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-000001.vmdk <zieluser>@<freenas-hostname>:<zielverzeichnis>

Prinzipiell sind ssh + rsync + Shellskript eine extrem bewährte und robuste Toolkombination. Nur die Fehlermeldungen von rsync sind oft wenig aussagekräftig.

Mit den Ergebnissen von oben ist es vielleicht sinnig das Problem mal im xsibackup Forum zu posten.

Abseits der Problemsuche: Grundsäztlich ist das mit dem rsync für kleinere VMs schon OK. Um Welten schneller funktioniert es aber, wenn xsibackup die vmdktools nutzen kann. Dazu ist ein natives vmfs-Dateisystem auf der Empfängerseite notwendig, was wiederrum mit iSCSI funktioniert.
 
Mit

Code:
ssh -i ../xsibackup_id_rsa root@192.168.0.115

Melde ich mich erfolgreich an der FreeNAS Konsole an. Mit ifconfig verifiziert.

Mit
Code:
./xsibackup-rsync -av -i ../xsibackup_id_rsa testfile.txt root@192.168.0.115:/mnt/Storage/esxi


kommt dann allerdings
Code:
[root@localhost:/vmfs/volumes/593d21cc-547ee6e9-29a1-d05099722886/xsi-dir/bin] ./xsibackup-rsync -av -i ../xsibackup_id_rsa testfile.txt root@192.168.0.115:/mnt/Storage/esxi
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]
[root@localhost:/vmfs/volumes/593d21cc-547ee6e9-29a1-d05099722886/xsi-dir/bin]
 
Zuletzt bearbeitet:
Derzeit blinken beim Server 2 HDD Geld und sollten ausgetauscht werden.
Wie geht man das am besten an ohne einen Datenverlust zu riskieren?
 
Ich spreche nicht vom Physischen sondern logischen ersetzen.
Kann ich den Raid Controller sagen " hey schiebe die daten von der HDD X auf die HDD Y" ?
 
Nope. Du kannst nur Datenträger ersetzen und dann errechnet der Controller bzw. das OS die "verlorenen" Inhalte anhand der Inhalte auf den übrigen Datenträgern bzw. Parity-Informationen.

Und wenn der Controller einen Austausch von zwei HDDs anrät, ist spätestens jetzt ein Backup dringend angeraten! Denn während du die erste "gelbe" Platte austauschst und der Controller zur Wiederherstellung wild rumrödelt, dürfte Dir mit hoher Wahrscheinlichkeit die zweite "gelbe" Platte ausfallen. Keine Ahnung welches Raidlevel du fährst, aber wenn Du nicht wenigstens ein Raid 6 bzw. Raidz2 hast, ist dann Ende.

Warum Backup vor Plattentausch: Wegkopieren erzeugt weniger Last als Raid-Rebuild - Deine Chancen eines erfolgreichen Komplett-Backup-Vorgangs sind also höher als der eines erfolgreichen Rebuilds.
 
Zuletzt bearbeitet:
Ahjo, dann wäre mal interessant zu erfahren, in welchem genauen Zustand dein Raid gerade ist, insbesondere ob das Hotspare schon benutzt wird...
 
Mit

Code:
ssh -i ../xsibackup_id_rsa root@192.168.0.115

Melde ich mich erfolgreich an der FreeNAS Konsole an. Mit ifconfig verifiziert.
Soweit so gut.
Mit
Code:
./xsibackup-rsync -av -i ../xsibackup_id_rsa testfile.txt root@192.168.0.115:/mnt/Storage/esxi

kommt dann allerdings
Code:
[root@localhost:/vmfs/volumes/593d21cc-547ee6e9-29a1-d05099722886/xsi-dir/bin] ./xsibackup-rsync -av -i ../xsibackup_id_rsa testfile.txt root@192.168.0.115:/mnt/Storage/esxi
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]
[root@localhost:/vmfs/volumes/593d21cc-547ee6e9-29a1-d05099722886/xsi-dir/bin]
Mist, das war mein Fehler. So geht es gar nicht. Der -i Parameter hat bei rsync eine ganz andere Bedeutung. Bei mir hat es zufällig funktioniert, weil der Key von dem User auch schon eingetragen war und er den xsibackup Key dann gar nicht gebraucht hat.

Die richtige Syntax ist:
Code:
./xsibackup-rsync -av -e 'ssh -i ../xsibackup_id_rsa' testfile.txt root@192.168.0.115:/mnt/Storage/esxi
 
Danke, werde ich testen.Sobald ich wieder auf das FreeNAS komme....

Musste meinen PC resetten, weil die BIldausgabe gesponnen hat, dabei hats die VM zerschossen -.-

Scheint nur schwerer zu sein, als ich dachte..

- - - Updated - - -

Danke, werde ich testen.Sobald ich wieder auf das FreeNAS komme....

Musste meinen PC resetten, weil die BIldausgabe gesponnen hat, dabei hats die VM zerschossen -.-

Scheint nur schwerer zu sein, als ich dachte..


Code:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:JBjhx6XnE9C7NTmwka3me9vBnuJWEBWha3iMv57y9CQ.
Please contact your system administrator.
Add correct host key in /.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /.ssh/known_hosts:1
ECDSA host key for 192.168.0.115 has changed and you have requested strict checking.
Host key verification failed.
Cannot find an authorized_keys file at 192.168.0.115
Tip: you might need to install additional OpenSSL components,
or just create the file for your OS, it usually requires 0600 permissions
Killed

Ich habe die Key neu generiert und im Root Nutzer eingetragen..wie ich es davor auch gemacht habe..ich habe den Key auch in die SSH Dateien im Freenas eingetragen - auch wenn es die eine Datei gar nicht gibt, wenn ich sie selbst erstelle funktionierts auch nicht...
 
Zuletzt bearbeitet:
Danke, werde ich testen.Sobald ich wieder auf das FreeNAS komme....

Musste meinen PC resetten, weil die BIldausgabe gesponnen hat, dabei hats die VM zerschossen -.-

Scheint nur schwerer zu sein, als ich dachte..

- - - Updated - - -

Danke, werde ich testen.Sobald ich wieder auf das FreeNAS komme....

Musste meinen PC resetten, weil die BIldausgabe gesponnen hat, dabei hats die VM zerschossen -.-

Scheint nur schwerer zu sein, als ich dachte..


Code:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:JBjhx6XnE9C7NTmwka3me9vBnuJWEBWha3iMv57y9CQ.
Please contact your system administrator.
Add correct host key in /.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /.ssh/known_hosts:1
ECDSA host key for 192.168.0.115 has changed and you have requested strict checking.
Host key verification failed.
Cannot find an authorized_keys file at 192.168.0.115
Tip: you might need to install additional OpenSSL components,
or just create the file for your OS, it usually requires 0600 permissions
Killed
OK, da steht im Prinzip alles drin. Also "Offending ECDSA key in /.ssh/known_hosts:1" > Key mit der Nummer 1 aus der known_hosts löschen und neu verbinden.
Ich habe die Key neu generiert und im Root Nutzer eingetragen..wie ich es davor auch gemacht habe..ich habe den Key auch in die SSH Dateien im Freenas eingetragen - auch wenn es die eine Datei gar nicht gibt, wenn ich sie selbst erstelle funktionierts auch nicht...
Perfekt. Was mir schon häufiger passiert ist, die authorized_keys darf nur "rw" Permissions für den Owner haben. Sonst wird sie einfach ignoriert. Darauf wird in der Fehlermeldung beiläufig auch hingewiesen.
 
Per Hand

Nach dem ich den RSA Key zum x ten mal erneuert habe, funktioniert die Übertragung der Testdatei.
Eine ISO konnte ich auch erfolgreich übertragen, nur bei den vmdk, fängt er an und ist dann mit 1 KB fertig - als erfolgreich, ohne Fehlermeldung..

Backupskript

Die VMX, NV, etc. Dateien überträgt er und bei den vmdk meldet er wieder den "--server: command not found" Fehler


Ich dachte erst, es liegt vlt. daran dass die HDD mit Thin provisioning erstellt wurden, allerdings ist die vom Filer eine Thick - erstellt und hochgeladen mit VMWare Workstation.
Due Linuxe sind Thin und im ESXi erstellt.


Das ist der aktuelle Stand.
 
Zuletzt bearbeitet:
Per Hand

Nach dem ich den RSA Key zum x ten mal erneuert habe, funktioniert die Übertragung der Testdatei.
Eine ISO konnte ich auch erfolgreich übertragen
Das ist doch schon mal gut. Wir wissen jetzt, dass ssh und rsync funktionieren.
, nur bei den vmdk, fängt er an und ist dann mit 1 KB fertig - als erfolgreich, ohne Fehlermeldung..
Die vmdk-Datei ist physikalisch auch nur 1kb groß. Die vmkd-Dateien kannst du dir mit vi oder cat mal anschauen. Sie enthalten eine textuelle Beschreibung der Platte und einen Verweis auf die echte Datendatei (-flat.vmdk). So weit ist das in Ordnung. Für das XSIBackup ist es auch wichtig, dass die "-flat.vmdk" und "-delta.vmdk" auch genauso heißen.

Hinweis: Im ESX-Datenspeicherbrowser werden die Dateien nicht so angezeigt, wie sie physikalisch vorhanden sind. Das kann beim direkten Arbeiten mit den Dateien etwas irritieren, sorgt aber in der täglichen Benutzung z.B. für konsistentes Kopieren.
Backupskript

Die VMX, NV, etc. Dateien überträgt er und bei den vmdk meldet er wieder den "--server: command not found" Fehler

Ich dachte erst, es liegt vlt. daran dass die HDD mit Thin provisioning erstellt wurden, allerdings ist die vom Filer eine Thick - erstellt und hochgeladen mit VMWare Workstation.
Due Linuxe sind Thin und im ESXi erstellt.

Das ist der aktuelle Stand.
Es müsste im Dateisystem eine ".ERR..." Log-Datei liegen. Kannst Du dort mal hineinschauen, bzw. hier posten. Dort sollte auch das fehlgeschlagene rsync-Kommando drinstehen. Vielleicht wird damit schon einges klarer.
Der Konsolenoutput von XSIBackup wäre auch interessant.
 
Habe mit meinem ESXi Server ein Problemchen, hoffe ihr könnte mir weiterhelfen.
Im Einsatz habe ich einen Microserver Gen8. Habe jetzt nur mal zum Test ESXi 6.5 installiert und direkt mal auf die neuste Build 6.5d geupdatet.
Soweit so gut! Es ist ja bekannt, dass der AHCI Treiber Performance Probleme haben soll und man diesen deaktivieren kann, sodass er auf den Default zugreift:

esxcli system module set --enabled=false --module=vmw_ahci

Nachzulesen hier:
NXHut - IT and Windows - News: Fix slow disk performance (vmw_ahci driver) in ESXi 6.5

Wenn ich den Befehl dann absetze und Boote, kommt mein ESXi ganz normal hoch, jedoch ist nach ein paar Minuten Schicht im Schacht.
Webinterface nicht mehr erreichbar, SSH Session geht nichts mehr, Konsole kann ich mich einloggen, jedoch ist dann auch nichts mehr...Ping jedoch auf die Management Adresse geht noch.

Ich nehme mal an, irgendwas spamt den ESXi zu, seitdem ich diesen Befehl abgesetzt habe.

Kann mir hier jemand helfen?
 
Zuletzt bearbeitet:
Ich habed eine Antwort aus dem 33hops forum bekommen.

In short, XSIBACKUP-FREE 9.0.2 is only able to Rsync files between two ESXi boxes. Maybe you tried to Rsync to other OS?

Fals dir das klar war und ich es vergessen habe zu erwähnen, das ich den kostenlosen nutze.So möchte ich mich dafür entschuldigen - hätte ja ne menge Zeit gespart und Nerven..

Hatte mir zwar die Pro Features durchgelesen, aber eher flüchtig.Da ich erstmal schauen wollte ob ich mit der kostenlosen Version zu recht komme und dann ggf. die 120 € ausgebe, wenn es sich von den Features lohnt..hätte ich mal besser die Liste durchgelesen..
Da steht ja
Extended Rsync Support to a great variety of OSs & NAS devices (Linux/ Unix)
Mir war nur nicht klar, dass das Bedeutet der Free kann nur ESXi zu ESXi..
 
Ich habed eine Antwort aus dem 33hops forum bekommen.

"In short, XSIBACKUP-FREE 9.0.2 is only able to Rsync files between two ESXi boxes. Maybe you tried to Rsync to other OS? "

Fals dir das klar war und ich es vergessen habe zu erwähnen, das ich den kostenlosen nutze.So möchte ich mich dafür entschuldigen - hätte ja ne menge Zeit gespart und Nerven..
Das war mir nicht klar, zumal ich problemlos VMs auf ein Debian rsyncen kann (auch mit FREE).

Vor iSCSI hatte ich auch ESXi zu ESXi rsync. Das wird von XSIBackup insofern speziell unterstützt, als dass das mitgebrachte rsync automatisch auf den Ziel-ESX-Host kopiert wird, falls es dort fehlt.

Ich mag die Aussage auch nicht so recht glauben, zumal das rsync binary funktional kaum verändert wird:
" Since version 4.6.3 the original code of Rsync version 3.1.0 has been slightly modified to allow faster Delta algorithm checksums, by just increasing hardcoded max allowed block size. We have also increased the buffer sizes to improve transfer speed. This copy is neverthelessa an unmodified version of Rsync 3.1.0 without any of the above commented changes. "
Das hört sich jetzt nicht danach an, dass dort an den rsync-Parametern geschraubt wurde.

Aber ich kenne jetzt auch die Spezialitäten deines NAS nicht.

Hatte mir zwar die Pro Features durchgelesen, aber eher flüchtig.Da ich erstmal schauen wollte ob ich mit der kostenlosen Version zu recht komme und dann ggf. die 120 € ausgebe, wenn es sich von den Features lohnt..hätte ich mal besser die Liste durchgelesen..
Da steht ja

"Extended Rsync Support to a great variety of OSs & NAS devices (Linux/ Unix) "

Mir war nur nicht klar, dass das Bedeutet der Free kann nur ESXi zu ESXi..

Marketing-Sprech. "XSIBACKUP-FREE 9.0.2 is only able to Rsync..." kann man ja durchaus so deuten, dass XSIBackup ohne weitere externe Tools tatsächlich nur ESXi zu ESXi kann. Ein Debian-Rsync bringt es nicht mit, ein ESXi-rsync schon.

Was ist denn mit der .ERR..-Datei? Gibt es keine?
 
Hm verstehe, vlt teste ich dann mal Debian als Ziel.

Achja, das Log.Das gibt es nur bei Cron Jobs - bei der manuellen Eingabe hat man nur den Output in der Shell direkt.

Code:
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0.vmdk ]
[Filer_SRV08] error: --server: Command not found.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]
Info: transfering file [ /vmfs/volumes/591e15e6-ad565a88-bb76-d05099722886/Filer_SRV08/Filer_SRV08_0-flat.vmdk ]
--server: Command not found.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]

Da will er ja den --server Befehl interpretieren aber scheitert dran.
 
scheisse ich bin am ROTIEREN!
Ich kann mich nicht mehr im ESXi einloggen und mein Virtueller Pc ist auch nicht mehr erreichbar!
Was ist der default benutzername?!
Nicht das schon wieder meine Daten weg sind.....
 
ffuu....
Mein PW ist 8 stellig und nirgends gespeichert im Browser. Auf den einen virtuellen pc rennt ein Vierenschutz der andere schiebt nur daten von a nach b.
Mein laptop hat "nur" den Clamwin. Kann ich mir irgend wie was eingefangen haben?!
Die firewall am router ist auch denny all da sollte niemand von aussen rein kommen.

- - - Updated - - -

jetzt komme ich wieder auf den virtuellen pc (über rdp) das erste was ich mache ist mail backupen und auf einen anderen pc exportieren....
 
...und am besten das root-pw aufschreiben...
 
Kaum ist ein Problem gelöst, gibt es ein neues..

Wollte eine neue VM erstellen, doch beim Abschluss erscheint diese Fehlermeldung.(Egal ob Linux oder Windows)
Fehler.JPG

Es wäre die fünfte VM, allerdings habe ich keine Limits bez der Anzahl der VM gefunden.Woran kann das also liegen ? In der Browser Konsole steht auch nichts.

Gruß Lucky
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh