ESX / ESXi - Hilfethread

Auch ein Snapshot ist kein Backup, da die Dateien ja immer noch auf der selben Storage liegen. Wenn die SSD, die HDD, der Controller, das Netzteil oder der ganze Server dann ausfallen, sind auch die Snapshots weg.

Des weiteren machen Snapshots das System nur elend langsam, vor allen Dingen wenn man wenig I/O-Performance hat, wie es bei einer einzelnen HDD der Fall ist. Die Technik eines Snapshots ist ja folgende:
  • Der aktuelle Stand der Daten wird "eingefroren", d.h. auf die aktuell vorhandenen VMDKs werden ab diesem Zeitpunkt nur noch lesende Zugriffe zugelassen
  • Alle Änderungen innerhalb des Gast-Dateisystems werden in eine zusätzliche (Delta-)VMDK pro virtueller Festplatte geschrieben
  • Wenn lesend oder schreibend zugegriffen wird, muss sowohl in der ursprünglichen als auch in der zusätzlichen VMDK geschaut werden, ob die Daten geändert wurden. Wenn ja, werden die geänderten Daten gelesen, ansonsten die ursprünglichen
  • Wenn ein weiterer Snapshot angelegt wird, wird wiederum die zusätzliche VMDK "eingefroren" und eine weitere (Delta-)VMDK angelegt
  • Wenn dann diese Snapshots wieder gelöscht werden sollen, muss in allen Snapshots geschaut werden, welche Daten geändert worden sind und die aktuellste Veränderung wird in die ursprüngliche VMDK zurückgeschrieben
  • Währenddessen wird eine weitere VMDK erstellt, um die Änderungen, die während des Zurückschreibens der geänderten Daten verwendet wird, um Schreiboperationen auf die VMDK abzufangen
Des weiteren muss geschaut werden, wenn ein virtueller Domänencontroller läuft, dass es sein kann, dass die Domäne kaputt geht, wenn man diesen auf einen früheren Zeitpunkt zurücksetzt.

Alles in Allem ist es nicht empfehlenswert, Snapshots als "Backup" zu verwenden. Da würde ich eher ein NAS nehmen, was in einem anderen Raum (besser noch in einem anderen Brandabschnitt) steht, um die täglichen Sicherungen zu machen, und die USB-Platten eben noch als zusätzliche wöchentliche Sicherung zu haben.

Vielen Dank für deine Mühe. Habs verstanden :-) Hab nur gedacht, dass ich den Snapshot auf eine zusätzliche HDD im Server auslagern kann und damit "frei" von der HDD mit den Files bin.

Auch Danke an gea.


Aktuell mache ich das Backup (mit Veeam) über eine Windows VM die auf dem selben Server liegt. Das Backup dauert dementsprechend sehr lange, das letztes hat über 30h gedauert....
Meine Idee ist jetzt nur, dass ich im Server noch ne HDD einbaue und darüber ein kurzfristiges "Backup" laufen lassen (jeden Tag um zumindest die 7 Tage zu verkürzen). Bin natürlich dementsprechend nicht vor Überspannung, Brand etc geschützt.

Ein zusätzliches NAS ist halt nochmal ne Preisfrage (bin aktuell als Student nicht so flüssig :-D). Anderes Zimmer fällt auch flach, da ich in ner 1 Zimmer Wohnheim Bude wohne (Server steht aktuell in der Küche). Backup übers Internet gehen auch schlecht (zB Backup Server ist bei meinen Eltern), da der Wohnheimanschluss mit einem Volumen begrenzt ist...
Falls
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ein zusätzliches NAS ist halt nochmal ne Preisfrage (bin aktuell als Student nicht so flüssig :-D).

Gängige Praxis ist es, das NAS zu virtualisieren -
Idealerwerweise nimmt man dazu einen extra Controller für die Platten oder man macht physical Raw Disk Mapping
(Zuweisen einzelner Platten an die NAS-VM)
 
Gängige Praxis ist es, das NAS zu virtualisieren
Öhm, das NAS wäre in diesem Falle nur für das Backup zuständig, und das auf die selbe Hardware zu packen ist ungünstig.

Wenn man ein NAS für die tägliche Arbeit nutzen will und schon einen Virtualisierungshost hat, stimme ich zu, aber in diesem Fall nicht. ;)
 
Nein, die NAS VM nimmt man nicht für Backup, sondern als Primärstorage für die VMs -
nur halt mit unendlich mehr Möglichkeiten als ein einfaches lokales vmfs Datastore.
 
Es dürfte allerdings reichlich kompliziert werden, bei begrenzten vorhandenen Ressourcen (eine SSD plus eine HDD und wenig Möglichkeiten da auch noch Geld zu investieren) da jetzt noch irgendwo eine NAS-VM aufzusetzen, weil der Großteil des Platzes wahrscheinlich aktuell schon von den VMs belegt ist...

Ich stimme dir wie gesagt zu, wenn man entweder einen Virtualisierungshost mit genug Ressourcen hat oder gerade einen neuen Virtualisierungshost einrichtet, aber in diesem Falle (was ich auch schon oben geschrieben habe) wird das wohl nichts.
 
Es dürfte allerdings reichlich kompliziert werden, bei begrenzten vorhandenen Ressourcen (eine SSD plus eine HDD und wenig Möglichkeiten da auch noch Geld zu investieren) da jetzt noch irgendwo eine NAS-VM aufzusetzen, weil der Großteil des Platzes wahrscheinlich aktuell schon von den VMs belegt ist...

Ich stimme dir wie gesagt zu, wenn man entweder einen Virtualisierungshost mit genug Ressourcen hat oder gerade einen neuen Virtualisierungshost einrichtet, aber in diesem Falle (was ich auch schon oben geschrieben habe) wird das wohl nichts.

Neja, die VM, welche eine Storagelösung virtualisiert, kostet ja effektiv keinen Platz... Man müsste eigentlich einfach nur ein Medium beschaffen (bei ESXi 6 gehen ja mittlerweile sogar USB Sticks als Datastore tiefenentspannt einzusetzen), wo man die NAS VM drauf drückt. -> die SSD/HDD dann via RDM an die NAS VM und von dort mit ZFS Filesystem und NFS an den Host zurück gemountet. Das kostet nix an Platz, da der einzige Mehrverbrauch durch die NAS VM Container bspw. auf dem USB Stick abgefackelt wird.

Mit so einer Lösung benötigt man bestenfalls etwas CPU Rechenzeit sowie 2-4GB RAM für den Anfang. Wenn man auf das Caching verzichtet, was ohne USV und sonstige Absicherungen gegen Ausfall gar nicht wirklich sinnvoll ist, tuts wohl auch weniger RAM.
-> der klar ersichtliche Vorteil ist, dass man dann via ZFS Storagesnapshots erstellen kann, wie man lustig ist -> und über eine Lösung jeglicher Art diese Storagesnapshots einfach wegsichern kann... Das ist halt extrem viel aufwendiger, wenn man die Snaps via ESXi Host erstellt und dort dann eine Drittsoftware notwendig ist, die die Daten vom VMFS Storage fischen kann.
Da er ja Veeam als Lösung nutzt, wäre es technisch sogar denkbar, dass die ZFS Snaps mit dieser Software gebackupt werden. Je nach Lösung/Lizenz sogar über WAN oder halt wohin man es gern hätte...



@gea
da ich bei mir für die Zukunft eine ähnliche Lösung mal probieren wollen würde, kannst du mir aus dem Hut sagen, ob man mit dem ZFS System bzw. deinen Templates irgendwie einen SSD Cache vor ein HDD Storage bekommt? Ich nutze aktuell 2x SSDs und 2x HDDs im Raid 1 -> an einem Hardware Raid Controller. Würde wohl die Disks dann an eine VM hängen und via ZFS die "Raids" bauen. Die Frage ist, erhalte ich irgendwie einen Vorteil von den SSDs, außer diese, wie jetzt auch schon, 1:1 als Storage zu nutzen? -> denn das ist eigentlich schade um den schnellen Platz. Meine SBS 2011 VM hat Systemseitig eine 100GB VMDK -> was schlapp mal die Hälfte der SSDs wegfrisst. Sinnvoller würde ich es finden, wenn man irgendwie mit HotBlocks und einem SSD Cache arbeiten könnte -> da HDD Platz deutlich billiger ist und damit auch andere VMs vom SSD Speed profitieren würden, wenn dort mal was "los" ist...
Gibts da Möglichkeiten??
 
Zuletzt bearbeitet:
@gea
da ich bei mir für die Zukunft eine ähnliche Lösung mal probieren wollen würde, kannst du mir aus dem Hut sagen, ob man mit dem ZFS System bzw. deinen Templates irgendwie einen SSD Cache vor ein HDD Storage bekommt? Ich nutze aktuell 2x SSDs und 2x HDDs im Raid 1 -> an einem Hardware Raid Controller. Würde wohl die Disks dann an eine VM hängen und via ZFS die "Raids" bauen. Die Frage ist, erhalte ich irgendwie einen Vorteil von den SSDs, außer diese, wie jetzt auch schon, 1:1 als Storage zu nutzen? -> denn das ist eigentlich schade um den schnellen Platz. Meine SBS 2011 VM hat Systemseitig eine 100GB VMDK -> was schlapp mal die Hälfte der SSDs wegfrisst. Sinnvoller würde ich es finden, wenn man irgendwie mit HotBlocks und einem SSD Cache arbeiten könnte -> da HDD Platz deutlich billiger ist und damit auch andere VMs vom SSD Speed profitieren würden, wenn dort mal was "los" ist...
Gibts da Möglichkeiten??

ZFS nutzt ja von Hause aus RAM (als Hausnummer alles > ca 1 -2GB) als ultraschnellen rambasierten ARC Readcache. Den kann man durch eine SSD als L2ARC vergrößern. Man muss dazu lediglich die SSD dem Pool als L2ARC readcache hinzufügen.

Ich würde aber eher die zeitkritischen VMs auf einem SSD Pool lassen und den normalen Pool für den Rest nehmen. Ein L2ARC kann was brigen, mehr RAM als ARC Lesecache bringt aber erheblich mehr als SSD cache.

ZFS nutzt auch automatisch einen kleinen Teil des RAM (ca 5s Schreiben) als Schreibcache um aus vielen kleinen langsamen Random Writes ein grosses schnelles sequentielles Write zu machen. Wenn man das für ESXi/NFS absichern möchte (quasi wie bei einem Hardware Raid die BBU) kann man auch eine SSD oder eine SSD Partition als Slog device nehmen. Die sollte dann aber richtig gut sein (geringe Latenz, hohe iops, Powerloss Protection).

Den Hardware Raidcontroller wird man für ZFS vermutlich nicht einsetzen können.


ps
Das man unter ESXi 6 USB (eventuell keinen Stick sondern besser eine USB SSD) als Datastore einsetzen kann ist mir neu. Ist da was zu beachten. Wäre für All-In-One ohne vt-d sehr interessant
 
Zuletzt bearbeitet:
die SSD/HDD dann via RDM an die NAS VM und von dort mit ZFS Filesystem und NFS an den Host zurück gemountet.
Beide Platten dürften aktuell ein großes Volume mit VMFS beinhalten. Wie soll man dort ein Volume mit ZFS drauf packen? Bin ich der einzige, der dieses Problem sieht?
 
@Eye-Q
Daten weggsichern und auf die neue NAS-VM verschieben?
 
Ich würde aber eher die zeitkritischen VMs auf einem SSD Pool lassen und den normalen Pool für den Rest nehmen. Ein L2ARC kann was brigen, mehr RAM als ARC Lesecache bringt aber erheblich mehr als SSD cache.

Neja, das wäre klar die Idealvorstellung... Mein Problem ist eher, dass eben dort Platz aus meiner Sicht sinnlos verbraten werden. Wenn so ne SBS 2011 Install mal ein paar Jahre auf dem Buckel hat, sammeln sich da GB weise Daten an. Das liegt schön alles im Systemroot, entsprechend groß der Spaß. Nur muss quasi dieses Systemroot schon schnell sein, damit das richtig lüppt, da sonst das Ansprechverhalten klar extrem in den Keller geht...
Ich wollte halt die Platzverschwendung der ganzen Coldblöcke vermeiden... Deswegen die Idee. Wären die SSDs deutlich billiger, dann wäre das auch kein Problem.

Mein Raidcontroller kann ebenso SSD Cache nutzen. Wie auch immer der das Ganze dann genau fabriziert -> sprich unter der Decke oder direkt als Zusatzspeicher im Volume, keine Ahnung, hab damit bis dato keine Erfahrung. Nur wenn ich die Hütte einmal auseinander reiße, dann kann man es ja gleich richtig machen.

ps
Das man unter ESXi 6 USB (eventuell keinen Stick sondern besser eine USB SSD) als Datastore einsetzen kann ist mir neu. Ist da was zu beachten. Wäre für All-In-One ohne vt-d sehr interessant

So neu ist das eigentlich nicht... Es soll wohl sogar unter 5.x schon gegangen sein. Aber mit erheblichem Konfigaufwand...
Beim 6er schaltest du den "usbarbitrator" Dienst aus, modelst den Stick auf GPT und kannst dann dort ein Datastore drauf ablegen... Nach nem Boot ist der Dienst aber wieder aktiv -> man kann diesen aber auch permanent abschalten. Der ist wohl irgendwie dafür da, dass man USB Geräte zu VMs durchreichen kann.

PS: guckst du hier bspw.:
USB Devices as VMFS Datastore in vSphere ESXi 6.0 | Virten.net

Für so ne Storage VM Lösung wäre das in der Tat sehr interessant. -> USB Sticks mit SLC Speichern gibts ja, sind zwar teuer, aber das macht die ganze Geschichte schon sehr flexibel...

EDIT: wenn du es dir einfacher machen willst -> nimm das Web Host Tool (also die aktuelle Beta davon) -> lösch die Partition(en) des Sticks und leg das Datastore schön über den Webclient an... -> so hab ich das gestern gemacht. Der Dienst muss aber wohl trotzdem ausgeschalten werden, da der sonst dazwischen funkt.
 
Zuletzt bearbeitet:
Hi Esxi´ler


ich bitte um einen Tipp - ich möchte (muss) genau diese Esxi Version (5.0.0u3 Build 1311175) in einer Testumgebung installieren.

Der Mainboard Chipsatz (Intel C2758) wird aber nicht erkannt - folglich finde ich im Installer kein Storage.
=> Lege ich aber die Esxi 5.5.0u1 Build 1623387 ein, sehe ich meine SATA Festplatte und kann installieren.

Meine Überlegung war nun herauszufinden welche SATA-AHCI Treiber in der 5.5.0u1 enthalten sind und diese in die 5.0.0u3 zu integrieren.

Nach Recherche habe ich mir die sata-ahci_3.0-18vmw.550.1.15.1623387.vib heruntergeladen und mittels Esxi-Customizer in meine 5.0.0u3 Build 1311175.iso integriert.
=> es geht aber noch immer nicht - nach wie vor wird die SATA HDD nicht gefunden.

Darum meine Frage an euch: Ist das prinzipiell möglich? Was habe ich übersehen?
 
Ich habe jetzt schon längere Zeit gesucht, aber mangels Begriffen stell ich meine Frage jetzt hier.

Gibt es in ESXi die Möglichkeit eine VM zu rebooten wenn die IP nichtmehr erreichbar ist.
Ich suche so etwas wie einen IP Watchdog.

Ich wäre für eure Hilfe sehr dankbar.

Mfg
Chrilly-X
 
Gegenfrage: was willst Du damit erreichen bzw. wo liegt das Problem? Mit so einer Automatik hast Du vielleicht das Symptom, aber nicht die Ursache bekämpft. ;)
 
@Chrilly-X: Wenn der ESXi erreichbar ist, kannst du jede VM die darauf läuft neu starten oder dich auch per "Konsole" auf diese schalten und einen Neustart durchführen oder was auch immer nötig ist.
 
Er möchte wohl einen automatischen Neustart der virtuellen Maschine über die VMWare Tools auslösen, wenn die IP-Adresse der Netzwerkkarte der virtuellen Maschine nicht mehr auf ping antwortet. :fresse:
 
Er möchte wohl einen automatischen Neustart der virtuellen Maschine über die VMWare Tools auslösen, wenn die IP-Adresse der Netzwerkkarte der virtuellen Maschine nicht mehr auf ping antwortet. :fresse:

Genau so ist es.

Eigentlich ist es heute das Erstemal passiert dass sich meine Ubuntu VM abgeschossen hat.
Nur hatte ich dann auf der Arbeit gleich Telefonterror von Zuhause.
Deshalb jetzt diese Idee, um somit gleich alle VMs am laufen zu halten.

Gibt es da etwas?
 
Failover Cluster? ;-) Sorry, nicht wirklich hilfreich.
 
Steig auf KVM um. ;)
Da kannst du dir solche Szenarien einfach zusammen Scripten, ESX ohne vCenter sit einfach nur eine Qual.
 
Verständnisfrage: Warum kann ich mit einer nicht VT-D fähigen CPU (& Mainboard) eine Netzwerk PCI Karte mit Umweg über vLan "durchreichen", aber eine normale PCI Karte nicht? Gibt es dafür ebenfalls einen Umweg (von mir aus auch CPU lastig)?
 
Wenn Du auf die virtuellen Switches anspielst: bei der Netzwerkconnectivität handelt es sich um eine zentrale Funktion des Hosts, die dieser quasi in Software mit Basisfunktionen "immer" bereitstellt, zur Not über eine Vollvirtualisierung der entsprechenden möglichst weit verbreiteten Standard-Hardware (Intel) in Software (entsprechend performant oder halt auch nicht), je nachdem wie gut die Unterstützung dafür in der GastVM ist.
Das ganze lässt sich vielleicht auch mit normalen Routingfunktionen vergleichen, die jeder Linuxkernel von Haus aus (Hardware unabhängig) kann.
Das machen die (ESXi, Hyper-V & Co.) aber eben nur für ganz fundamentale Funktionen und nicht für Deine TV Karte oder sonstige PCI Geräte die dann im Host virtualisiert bzw. "simuliert" bereitgestellt werden müssten.

Der vDT Passthrough macht im Prinzip genau das Gegenteil: der Host kümmert sich quasi gar nicht mehr um das Gerät, sondern über lässt den Schlamassel der zugeordneten VM, die dann sehen muss, ob sie die (Hardware)Treiber bekommt.

- - - Updated - - -

...mit der bekannten Einschränkung, dass eben die "Übersetzung" des PCIe-Geräts in Software und die Trennung auf dem Bus an die VM in der VirtualiserungsSoftware bestimmt nicht trivial ist und eben die zusätzlichen CPU Features braucht, damit das Spaß macht.
 
Hallo,

Ich hätte ein paar Fragen (ab 1.2.2016 braucht ihr euch keine Arbeit mehr machen dann ist das Thema wohl "gegessen":
Das Supermicro X11SSi-LN4F retail (MBD-X11SSi-LN4F-O) Preisvergleich wird laut Hersteller ja wohl unterstützt (A² -> non Raid /AHCI) ( Super Micro Computer, Inc. - Support | OS Compatibility Chart )
- Ist es möglich eine m.2 NVM SSD über einen Adapter für ESXi zu Nutzen (950pro) - laut Amazon wird die SSD ja direkt "durchgereicht" und kein Treiber ohne ähnliches für die Adapter benötigt.
- lässt sich ESXi auf Supermicro SuperDOM 32GB (SSD-DM032-PHI) Preisvergleich installieren?
- wie warscheinlich wäre es ESXi hierlauf zum laufen zu bekommen: ASUS P10S-E/4L (90SB0520-M0UAY0) Preisvergleich

danke schon mal fürs lesen ;)

offtopic:
Kauf eines neuen "Server´s" steht an, und ich hätte gerne ESXi drauf, bisher nur die letzten Tage diverse Posts zu Whiteboxen gelesen, sonst noch keinen "wirklichen" Kontakt mit ESXi gehabt.
http://www.hardwareluxx.de/communit...grober-plan-steht-schon-exchange-1105212.html
 
Zuletzt bearbeitet:
Ich hab über SSH mit vmkfstools -z erfolgreich eine HDD an eine Windows 7 VM durchgereicht. Unter Windows 7 zeigt es mir unter der Computerverwaltung folgendes an: Offline (Der Datenträger ist aufgrund einer von einem Administrator festgelegten Richtlinie offline.)

Bildschirmfoto 2016-01-26 um 20.00.13.jpg

Ich bin nach diesem Tutorial vorgegangen: VMware ESXi: Lokale Festplatte als Raw Device Mapping (RDM) einbinden | blog.bistron.eu

Hat jemand Ideen? Vielen Dank!
 
Rechtsklick -> Online funktioniert nicht?
Ggf. musst du das 2x machen, nämlich mit initialisieren (die Wahl ob MBR oder GPT) nochmal...
 
Hallo zusammen,

ich benötige mal eure Hilfe, da ich im Netzwerkbereich doch eher mit schlechten Kenntnissen ausgestattet bin. Ich habe ein ESXi 6 Server (siehe Sig) im Einsatz der zwei Netzwerkkarten (onBoard) an einem vSwitch hängen hat. Nun möchte ich aber produktives Netz von einem noch zu erstellenden Testnetzwerk trennen. Dazu benötige ich eine grobe Anleitung wie ich dies im ESXi trenne. Mir steht dazu noch ein managebarer HP Switch sowie eine Sophos UTM (beide Ports belegt) zur Verfügung.

Das Testnetzwerk möchte ich dann, bis auf ein paar Ports, so einrichten, dass es sich nicht mit dem produktiven kollidiert (DHCP, DNS, etc).

Für Hilfe bin ich sehr dankbar.

Grüße
 
Darf das Testnetzwerk auch innerhalb des ESXi bleiben oder soll das auch nach extern kommen?
Im ersteren Falle kannst Du einfach einen virtuellen Switch ohne physikalische Netzwerkkarte erstellen und da das gesamte virtuelle Testnetzwerk anschließen.
Wenn das nach extern kommen soll, wird es schwieriger, wenn es nur einen physikalischen Switch und eine Firewall ohne freien Netzwerkanschluss gibt. Man kann zwar prinzipiell mit VLANs arbeiten und das so sauber trennen, das ist aber nicht ohne und mit "eher schlechten Kenntnissen" kann man da viel fehlkonfigurieren.
 
Du könntest eine weitere Netzwerkkarte in die UTM einbauen und eine der beiden Karten am ESXi an einen weiteren vSwitch binden. Damit erreicht du eine Trennung bei gleichzeitiger Möglichkeit zwischen beiden Netzen kommunizieren zu können.
Alternative wäre bspw. eine zusätzliche UTM (oder andere Appliance mit Routing und ggf. Firewall Funktion) virtuell auf den ESXi zu installieren -> ebenfalls einen zusätzlichen vSwitch anlegen, aber ohne physische Netzwerkkarte. Die virtuelle Appliance hat dann ein Bein am neuen vSwitch und eins am vorhanden. Dazu brauch es auf deiner externen UTM eine statische Route für das Testnetz.
Möglichkeit 3 wäre eine VLAN Trennung... bei nem HP Switch mit klicki bunti Webinterface ist das kein Hexenwerk. Du brauchst einfach nur ein zusätzliches VLAN (mit anderer ID als dem default VLAN). Sinnvollerweise stellst du deine Ports vom ESXi sowohl am Switch als auch am Server auf tagged für beide VLANs. Als Access VLAN kann ja das Default VLAN bestehen bleiben, dann schießt du dich auch nicht selbst ab... Dazu das gleiche für den Switchport der UTM. Das erlaubt dir, quasi beliebig viele virtuelle Netze am ESXi und auf der UTM anzulegen. Default Gateway für diese Netze kann dann die UTM spielen.

Dass es "zu schwer" wäre, so was einzurichten, würde ich nicht sagen... wenn man damit spielen will, sollte man doch wenigstens die absolute Basis verstanden haben ;) viel mehr als Basis ist das nun nicht...
Ich halte die VLAN Lösung für sie sinnvollste, da du damit flexibel bist für weitere Spielereien... Nachteile hat es auch nicht. Bestenfalls der Bedarf nach nem VLAN fähigen Switch, aber der ist ja vorhanden...
 
Zuletzt bearbeitet:
Mit VLANs scheint mir persönlich auch die beste Möglichkeit zu sein. Zumal ich dann nicht noch 20 Euro für zwei Netzwerkkarten ausgeben muss. :d

Dann werde ich mal gucken ob ich das hin bekomme. Wie gesagt ist mein Netzwerkknowhow in diesem Bereich doch sehr eingeschränkt, aber mit den Anforderungen wächst man ja bekanntlich. :)
 
Bzgl. Backup:

Ich hab mir auf meinem ESXi Host eine Backup VM erstellt und die habe ich so eingerichtet, dass jeden Tag automatisch auf einer durchgereichten internen HDD mit Veeam ein inkrementelles Backup darauf erstellt wird (HDD ist mit NTFS formatiert, und die durchgereichte HDD ist nicht mit einem extra Controller verbunden). Ich weis natürlich, dass dies kein richtiges Backup (ua räumliche Trennung), deshalb will bzw. mache ich wöchentlich noch ein manuelles Backup auf Externen (über USB angeschlossenen) HDDs.

Ist es intelligent, wenn ich die Backup Datei der durchgereichten HDD direkt auf die angeschlossene externe HDD kopiere oder soll ich dort ein extra Backup mit Veeam erstellen? Im ersten Fall funktioniert das Kopieren wesentlich schneller, im 2. Fall muss die externe HDD 2 Tage am Server angeschlosssen sein...

Zusätzlich sichere ich noch wichtige Dateien (hauptsächlich Fotos) per Drag & Drop auf externen NTFS formatierten HDDs. Bin mir gerade unschlüssig ob dies nicht überflüssig ist. Mit Veeam kann ich ja auch einzelne Dateien wiederherstellen, nur bin ich halt auf die Veeam Software angewiesen.

Wie macht ihr Euer Backup. Spricht irgendetwas gegen meine Vorgehensweise?


Vielen Dank :-)
 
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