Hallo, habe meine C: 128 ssd m.2 2280 mit clonzilla auf eine 512 geklont. 128 raus, 512 rein, gestartet, klappt, die größe ist weiterhin 128Gb Bei dem Versuch über Datenträgerverwaltung den Rest C: zuzuweisen, erscheint mit Rechtsklick auf C: "Volume erweitern". Toll, ist aber ausgegraut, geht also nicht. Hat jemand eine Lösung? VG Walter
Walter L. schrieb: > Hat jemand eine Lösung? Windows mag nicht gerne an der Platte rumschrauben, von der es läuft? Hast du ein USB->m2 Gehäuse und einen zweiten PC? Oder du könntest versuchen, die Partition erstmal unter Linux zu vergrößern (Clonezilla hast du ja schon, und das sollte die nötigen Werkzeuge auch mitbringen)
Εrnst B. schrieb: > Windows mag nicht gerne an der Platte rumschrauben, von der es läuft? Kein Problem. Auch verkleinern ist live möglich, wenngleich mit Einschränkungen.
Walter L. schrieb: > habe meine C: 128 ssd m.2 2280 mit clonzilla auf eine 512 geklont. > 128 raus, 512 rein, gestartet, klappt, die größe ist weiterhin 128Gb Könnte sein, dass du erst einmal den MBR reparieren muss, damit der Rest der Disk sauber eingepflegt ist. Bei einer 1:1 Kopie von 128GB auf 512GB geht das extended partition record im MBR nur bis 128GB. Eine Live-CD mit gparted dürfte helfen. Geht vielleicht auch mit Windows' DISKPART, aber frag mich nicht nach Details.
:
Bearbeitet durch User
(prx) A. K. MBR, Live-C, gparted was ist das??? Ich glaube, ich gebe das Ganze in eine PC-Bude. Kostet 70 EURONEN pro LAPTOP. VG Walter
Hallo, meist liegt am Ende, also hinter der C-Partition noch eine Wiederherstellungspartition, das wird jetzt auch so sein. Dann kann Windows nicht vergrößern. Schau Dir Minitools an und verschiebe die nach hinten. https://de.minitool.com/partition-manager/partition-wizard-startseite.html Nutze ich in solchen Fällen seit Jahren problemlos und zuverlässig. Grußaus Berlin Michael
Walter L. schrieb: > MBR, Live-C, gparted was ist das??? MBR = Master Boot Record. Da steht u.A. die primäre Partitionierung drin. Eine Live-CD ist das, was du vmtl bei CloneZilla genutzt hast, d.h. eine bootfähige CD mit in diesem Fall gparted drauf. Gparted ist ein Linux-Programm zur Manipulation von Partitionen. Bevor Windows das selbst live beherrschte, war das auch in Windows ein einfacher Weg, C: zu vergrössern. > Ich glaube, ich gebe das Ganze in eine PC-Bude. Wenn du die Original-Disk noch als Fallback für den Fall der Vernichtung des Inhalts der neuen Disk hast, kannst du natürlich auch selbst rumprobieren.
Walter L. schrieb: > Ich glaube, ich gebe das Ganze in eine PC-Bude. Kostet 70 EURONEN pro > LAPTOP. Ein Tip bevor du es weggibst: Downloade dir das Programm "Hasleo WinToHDD", hier: https://www.easyuefi.com/backup-software/backup-suite-free.html Damit kannst du deine Platte klonen. In der Bezahlversion werden sämtliche Partitionen 1:1 geklont, jedoch in der Free-Version wird nur die primäre Partition geklont. Meistens reicht das auch. Dabei wird die Ziel-HDD komplett formatiert, d.h. bestehende Partitionen werden komplett zusammen gefasst. Probiers.
Beitrag #7221412 wurde vom Autor gelöscht.
Klonen ist nicht die geeignete Methode bei unterschiedlichen Größen. Nimm ein Backup-Tool, mache ein Systemabbild der alten SSD, und restore es auf der neuen SSD. Diese Tools wissen auch, was sie alles nicht kopieren müssen (Auslagerungsdatei, Papierkorb usw.), sind also deutlich schneller, als ein Kloner. Ich nehme den Aomei Backupper.
Peter D. schrieb: > sind also deutlich schneller, als ein Kloner. Was bei einer 128 GB SSD nicht wirklich dramatisch ist. CloneZilla optimiert obendrein ebenfalls, kopiert nur genutzte Inhalte und lässt ggf den Swapspace weg. Aber die Sache mit den Partitionen erledigen spezielle Windows-Progs wahrscheinlich wirklich gleich mit.
Peter D. schrieb: > Klonen ist nicht die geeignete Methode bei unterschiedlichen Größen. Wie kommst du auf dieses schmale Brett? Ich benutze verschiedene Programme zum Klonen, bei einem kann ich die verschiedenen Partitionsgrößen bequem mit einem Schieber festlegen.
Danke für wertvollen Tipps. Richtig, wird auch geschrieben, wenn neben C: noch was steht, ist „Volume erweitern“ ausgegraut. Bei mir müsste ich die Wiederherstungspartition löschen. Geht aber nicht. Muss mir wohl minitool holen, damit soll das fkt. VG Walter
Walter L. schrieb: > Wiederherstungspartition löschen Schon mal bei Google direkt nach diesen 2 Worten gesucht?
- Gparted laden: https://gparted.org/ - Nach Anleitung auf deren Seite z.B. einen bootfähigen Stick oder auch eine CD/DVD anfertigen - Davon starten - im grafischen Editor die Festplatte mittels Verschieben, Vergrößern, Löschen und Neu so zusammenferkeln wie es soll - "Übernehmen" - warten.... - ???? - Profit: kostet nix, macht was es soll, geht schnell und einfach, und wenn die originale SSD noch unangetastet da liegt auch völlig risikolos. Alternativ: - Macrium Rescue (ist auch kostenlos für privat) - auf USB-Stick laden - davon starten - Image des Originals machen - neue Platte einbauen - Image zurückspielen, dabei Partitionen anpassen
Walter L. schrieb: > habe meine C: 128 ssd m.2 2280 mit clonzilla auf eine 512 geklont. Da liegt schon der Fehler. ;) Hättest du beim Zurückspielen gesagt, er soll das Image aufblasen wären alle Probleme gelöst. Aber man macht auch kein CLONE-Backup sondern ein ganz normales VOLUMEN-Backup.
Schlaumaier schrieb: > Aber man macht auch kein CLONE-Backup sondern ein ganz normales > VOLUMEN-Backup. Mit Bordmitteln? Heise hat zwei Varianten aufgeführt, und realistisch kommentiert: https://www.heise.de/tipps-tricks/Backup-erstellen-mit-Windows-10-3858841.html
:
Bearbeitet durch User
Schlaumaier schrieb: > Aber man macht auch kein CLONE-Backup sondern ein ganz normales > VOLUMEN-Backup. NB: Im professionellen Umfeld sind Backups über Cloning recht verbreitet. Nicht zuletzt weil bei full restore schneller und zuverlässiger als bei file backup/restore. Aber auch inkrementell und selective restore geht.
:
Bearbeitet durch User
Hallo, Jens M. schrieb: > - Profit: kostet nix, macht was es soll, geht schnell und einfach, und > wenn die originale SSD noch unangetastet da liegt auch völlig risikolos. Gilt für die MiniTools auch, Bootstick ist nicht nötig, Ablauf sont wie bei GParted. Jens M. schrieb: > Alternativ: > - Macrium Rescue (ist auch kostenlos für privat) Bei mir Macrium Reflect Free. Image kann man auch aus dem laufenden System anlegen. Clone geht auch, bei Clone einer eingebauten HD/SSD auf ein Medium im ext. USB-Gehäuse kann es Überraschungen geben, wenn der USB-Controller eine andere Blockgröße meldet. Macrium warnt dann bzw. verweiger das Clonen. Gruß aus Berlin Michel
von (prx) A. K. (prx) >14.10.2022 16:14 Schon mal bei Google direkt nach diesen 2 Worten gesucht? Immer diese blöden Bemerkungen...(prx) A. K. (prx) schäme dich. So. ich habe es aus https://praxistipps.chip.de/wiederherstellungspartition-in-windows-loeschen-so-gehts_31288 Danach kann ich C: erweitern Zum Löschen der Wiederherstellungspartition gehen Sie wie folgt vor: Drücken Sie gleichzeitig auf die Tasten [Windows] und [R], sodass sich der Befehl "Ausführen" öffnet. Geben Sie hier "diskmgmt.msc" ein und bestätigen Sie mit "OK". Anschließend startet die "Datenträgerverwaltung". Suchen Sie nach der Wiederherstellungspartition und schauen Sie unten, auf welchem Datenträger sie liegt. In der Regel handelt es sich um den "Datenträger 0". Drücken Sie erneut auf [Windows] und [R] und geben Sie den Befehl "diskpart" ein. Bestätigen Sie wieder mit "OK". Geben Sie "select disk 0" ein, falls es sich bei Ihnen um den Datenträger 0 handelt. Geben Sie anschließend "list partition" ein und suchen Sie sich die Wiederherstellungspartition heraus. In unserem Fall ist es Partition 1. Schreiben Sie nun folgenden Befehl ein: "select partition 1". Weicht die Nummer bei Ihnen ab, passen Sie diese im Befehl an. Tippen Sie zum Schluss den Befehl: "delete partition override" ein. Anschließend wird die Wiederherstellungspartition entfernt. In der Datenträgerverwaltung können Sie den neuen freien Speicherplatz einer anderen Partition zuordnen. Hier zeigen wir Ihnen, wie Sie die Partitionen zusammenführen.
Hallo, natürlich kann man mit diskpart die Wiederherstellungspartition löschen wenn sie nciht mehr haben will. Die kann aber durchaus mal nützlich sein, bei mir darf sie also bleiben. diskpart hat für ungeübte benutzer auch den Nachteil, daß ein Tippfehler zum Verlust der falschen Partition oder mehr ausreicht. Man dann da auch Tipparbeit sparen: die Befehle von Diskpart lassen sich mit den ersten 3 Buchstaben abkürzen. sel dis 0 reicht also z.B. Ich beginne immer mit lis dis und schaue ob die Nummer Pallet die richtige ist. Dann meist sel dis 0 und lsi par, dann sehe ich nochmal, ob die Partitionen meiner Erwartung entsprechen. Gruß aus Berlin Michael
Michael U. schrieb: > Bei mir Macrium Reflect Free Sorry, das meinte ich auch. Rescue heißt das Medium bei mir auf dem Ventoy-Stick, da hatte ich einen Hirnschluss. Michael U. schrieb: > Image kann man auch aus dem laufenden > System anlegen. Das hab ich mich bislang nie getraut, weil ja letztendlich das System dann doch nicht benutzbar ist, denn in welchem Stand sind dann Programme die gerade laufen? Außer man lässt jetzt was unwichtiges wie den Browser offen, der kann leicht zurückgesetzt werden, aber z.B. ein CAD oder was Officemäßiges wäre mir da zu riskant. Wie sind da deine Erfahrungen?
Jens M. schrieb: > Das hab ich mich bislang nie getraut, weil ja letztendlich das System > dann doch nicht benutzbar ist, denn in welchem Stand sind dann Programme > die gerade laufen? Wird der Volume Shadow Copy Mechanismus genutzt, entsteht ein konsistentes Image. Das ist eine Art Snapshot des Systems auf NTFS Basis.
:
Bearbeitet durch User
Walter L. schrieb: > Immer diese blöden Bemerkungen...(prx) A. K. (prx) schäme dich. Schneeflocken sind nicht mein Ding.
Mit Schattenkopien und Exceldateien klappt das bei mir nicht, die sind dann "halb" und Excel meckert, oder sie sind "alt" und mir fehlt die gemachte Arbeit. So oder so kann ich also bestimmte Programme während des Imagevorgangs nicht nutzen. Wenn das der gleiche Mechanismus ist, weiß ich warum ich vom Stick ein Rescue-Medium starte, was im übrigen mit Ventoy seeehr komfortabel geht: Iso draufkopieren, läuft.
Jens M. schrieb: > Mit Schattenkopien und Exceldateien klappt das bei mir nicht, die sind > dann "halb" und Excel meckert, oder sie sind "alt" und mir fehlt die > gemachte Arbeit. So oder so kann ich also bestimmte Programme während > des Imagevorgangs nicht nutzen. Bei Schattenkopien ist beabsichtigt und Teil des Verfahrens, dass du den Stand des Systems erhältst, zu dem die Schattenkopie angelegt wurde. Inwieweit Anwendungsprogramme damit zurecht kommen, ist unterschiedlich. Einige Datenbanksysteme klinken sich in den VSS ein und stellen sicher, dass ihr Datensalat in einem Zustand ist, der den Snapshot anschliessend sauber und ohne hässliche Kommentare nutzbar macht. Andere Snapshot-Verfahren arbeiten eine Ebene tiefer auf Storage-Ebene und eine Involvierung des VSS ist zwar bei manchen aus dem gleichen Grund möglich, aber nicht zwingend. In diesem Fall enthält man einen Snapshot, in dem generell alle Disk-Aktivitäten aller Volumes vor Zeitpunkt X enthalten sind und alle danach nicht. Ein aus einem solchen Snapshot entstehender Klon ist in etwa vergleichbar mit einem System, das nach hartem Abschalten mitten im Betrieb neu gestartet wurde.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ein aus einem solchen > Snapshot entstehender Klon ist in etwa vergleichbar mit einem System, > das nach hartem Abschalten mitten im Betrieb neu gestartet wurde. Daher "Booten mit externem Medium" ;) Da hatte ich solche Probleme noch nie, wenn der Stick bootet ist das Image klar. Und der Stand ist auch fix und bekannt, wenn die Kiste normal runtergefahren wurde.
Jens M. schrieb: > Daher "Booten mit externem Medium" ;) Für den Fall des TE zweifellos. Hat er ja auch gemacht.
Walter L. schrieb: > habe meine C: 128 ssd m.2 2280 mit clonzilla auf eine 512 geklont. Ich finde meistens Vor-Partitionieren besser. Dann hat man auch mehr Möglichkeiten der Aufteilung des größeren Speicherplatzes. Wenn man gerne experimentiert, kann man auch gucken, welches Dateisystem sinnvoll ist, oder wie flexibel das ganze ist. https://de.wikipedia.org/wiki/Liste_von_Dateisystemen
Walter L. schrieb: > habe meine C: 128 ssd m.2 2280 mit clonzilla auf eine 512 geklont. > 128 raus, 512 rein, gestartet, klappt, die größe ist weiterhin 128Gb > Bei dem Versuch über Datenträgerverwaltung den Rest C: zuzuweisen, > erscheint mit Rechtsklick auf C: "Volume erweitern". Toll, ist aber > ausgegraut, geht also nicht. Das Problem ist das Du den 1. Sector mit geklont hast. Dort ist normalerweise auch die Größe der Platte hinterlegt. Windows meint nun das die Platte nich größer als 128GB ist und graut den Eintrag deshalb aus. Du mußt wahrscheinlich den MBR neu schreiben, dannach sollte es funktionieren.
rbx schrieb: > Walter L. schrieb: >> habe meine C: 128 ssd m.2 2280 mit clonzilla auf eine 512 geklont. > > Ich finde meistens Vor-Partitionieren besser. Dann hat man auch mehr > Möglichkeiten der Aufteilung des größeren Speicherplatzes. Hä? Bei einem Image zurückschreiben interessiert das gar nicht. Und nie clonen! Immer über ein Image gehen. Ich habe da schon wundersame Dinge erlebt.
Hallo, Jens M. schrieb: > Michael U. schrieb: >> Image kann man auch aus dem laufenden >> System anlegen. > > Das hab ich mich bislang nie getraut, weil ja letztendlich das System > dann doch nicht benutzbar ist, denn in welchem Stand sind dann Programme > die gerade laufen? Ich nutze es öfter, natürlich dann nur Sachen, deren Daten sowieso auf einer anderen HD liegen. Ansonsten gehe ich vom Stand bei Begin des Backups aus. (prx) A. K. schrieb: > Wird der Volume Shadow Copy Mechanismus genutzt, entsteht ein > konsistentes Image. Das ist eine Art Snapshot des Systems auf NTFS > Basis. Wird von Macrium genutzt. Ich habe das System-Image bisher noch nie wirklich nutzen müssen. Meist erstelle ich ein Image so nebenbei, wenn ich am System was ausprobieren will oder Win mit größeren Updates droht. Nach Murphy habe ich es noch nie gebraucht, weil ja nichts schief geht, wenn man ein BU hat. ;) Also Win Datenträgerverwaltung, Diskpart, Minitools Partition Wizard und Macrium Reflect Free. Ein Programm will ich noch erwähnen, das kostet allerdings: File Scavenger für "echte" Datenrettung und manchmal als "undelete". Das hat eine Vorgeschichte: ein Bekannter (Autowerkstatt) rief um Hilfe, weil sein Reparaturverwaltungsprogramm streikte. Alter 19" Server, alte Win 7 Server Installation, 2x IBM SCSI im Raid1. Eine HD war wohl schon Monate tot, das BU-Script lief sowieso schon ewig nicht mehr. Jetzt war die 2. HD am Ende. System fuhr aber noch soweit hoch. Alle gerade greifbaren Scantools versanken in ewiges Suchen oder fanden nichts. FileScavenger war mit Scannen nach 5 Minuten fertig und fand zumindest alle Files und die Struktur richtig. Da die Demo beschränkt war, kaufte ich den Lizenzkey und 2 Stunden später waren alle Files seines Programms bis auf eine wirklich defekte kopiert. Eine Ersatzplatte (besorgt schon, als die erste ausfiel und ins Regal gelegt, spielt ja noch alles...) war da. Raid Rebuild lief zum Glück mit Fehlermeldung durch. Sein altes Programm lief zum Glück, die Sekretärin hatte noch Nacharbeit, weil sie ein paar aktuelle Kundenadressen von Hand nachtragen durfte. Alles nur, weil guter Bekannter von mir mich aus Peking! anrief (der war dort für fast ein Jahr dienstlich) weil er nicht mehr auf den Server raufkam, den er dort sonst eben so nebenbei am Leben hielt. 2. Platte kam ein paar Tage später, die habe ich noch eingebaut, dann war wenigstens der Mirror wieder komplett, das BU-Script wurde per Fernzugriff auf Peking repariert usw. HDs waren die einigen sicher noch bekannten 18GB 10000U/min Wide-SCSI. Gruß aus Berlin Michael
(prx) A. K. schrieb: > Könnte sein, dass du erst einmal den MBR reparieren muss Wohl eher die GUID (GPT). Ein Datenträger mit mehr als einem protective MBR ist wohl eher die Ausnahme als die Regel, vor Allem da heute nichtmehr davon ausgegangen werden darf, dass CSM standardmäßig aktiviert oder überhaupt vorhanden ist.
Frage mal bei den Grünen. Da steht gerade Eine vor versammelter Mannschaft, die weiß, wie man sein Volumen erweitert. https://cdn.mdr.de/nachrichten/deutschland/politik/mdraktuell-parteitag-gruene-104-resimage_v-variantSmall16x9_w-576.jpg?version=58339
michael_ schrieb: > Und nie clonen! > Immer über ein Image gehen. Kommt darauf an. 😉 Beim richtigen Klonen sind die Sektoren von Ausgang- und Zielsystem absolut gleich, d.h. es können z.B. auch Lizenzschlüssel oder Programme, die am Betriebssystem vorbei auf die Platten zugreifen, kopiert werden. Bei einem echten Klon ist tatsächlich die Größe beider Dateisysteme gleich. Das kann aber später ggf. geändert werden (ist aber vom Dateisystem abhängig, ob das geht). Aber es ist schon richtig, daß man das heute nur noch relativ selten nutzt, weil das logischerweise erheblich langsamer ist, da auch leere Bereiche mitkopiert werden müssen. Das Image hingegen legt eine logische Kopie von Ausgangs- und Zielsystem an. Dabei ist die Kopie dann meistens auch gleich defragmentiert. Hier können leere Bereiche übersprungen werden, dadurch ist die Methode schneller. Und dann gibt es noch Programme für einen Transfer von einer Hardware auf die nächste, da manche Betriebssysteme zickig auf einen Wechsel der Hardware reagieren. Hier sollen alle speziellen Treiber und Erweiterungen entfernt werden, um in einer Art "Notfallmodus" neu zu starten. N.m.E. funktioniert das mehr oder weniger gut. Ich würde das jedoch nur dann machen, wenn es nicht anders geht. @Thema Evtl. läßt sich in der Datenträgerverwaltung der freie Platz als zusätzliche Partition nutzen und formatieren. Dann hätte man eben zwei logische Laufwerke, was ohnehin von Vorteil sein könnte (früher als man Win98 noch alle zwei Jahre neu installieren mußte, WAR das wirklich ein Vorteil).
kleiner Admin schrieb: > michael_ schrieb: >> Und nie clonen! >> Immer über ein Image gehen. > > Kommt darauf an. 😉 > > Beim richtigen Klonen sind die Sektoren von Ausgang- und Zielsystem > absolut gleich, d.h. es können z.B. auch Lizenzschlüssel oder Programme, > die am Betriebssystem vorbei auf die Platten zugreifen, kopiert werden. > Bei einem echten Klon ist tatsächlich die Größe beider Dateisysteme > gleich. Unsinn! Bei beiden Varianten kommt es auf das Verfahren an. Unter Win kann beim Clonen aber die Hive übelste Probleme bereiten. Kommt auf das Programm und die Einstellung an. kleiner Admin schrieb: > Das Image hingegen legt eine logische Kopie von Ausgangs- und Zielsystem > an. Siehe oben. Kommt auf das Verfahren an. Unter Win braucht es kein sektorweises kopieren.
kleiner Admin schrieb: > weil das logischerweise erheblich langsamer ist, da auch leere Bereiche > mitkopiert werden müssen. Wobei man Disks intelligent klonen kann und dann Partitionen klont, nicht einfach blind alles. CloneZilla verwendet partclone, vorausgesetzt es kennt das Filesystem. Das kopiert die Partition zwar im Prinzip 1:1 auf Blockebene ohne Defragmentierung etc, lässt aber leere Bereiche weg, ebenso Swap- und Hibernate-Files. https://partclone.org/ Ob das direkt zwischen Devices erfolgt, oder unter Zwischenschaltung von Image-Files, ist hinsichtlich des Verfahrens unerheblich.
:
Bearbeitet durch User
kleiner Admin schrieb: > Beim richtigen Klonen sind die Sektoren von Ausgang- und Zielsystem > absolut gleich, d.h. es können z.B. auch Lizenzschlüssel Intelligente Verfahren zum klonen können auf Blockebene kopierte Ziele zusätzlich mit Methoden anreichern, die bei ersten Start Modifikationen durchführen, um beispielsweise System-ID und -Namen zu ändern und den Lizenzschlüssel neu einzutragen. Microsoft hat dazu ein Verfahren definiert, das nebenbei auch bestimmte Einstellungen auf den Ursprungszustand zurücksetzt. Siehe Sysprep. Die wird interessant, wenn man damit Systeme ausrollt, routinemässig eine Vorlage repliziert.
:
Bearbeitet durch User
Das ist letztlich eine Frage der Definition. Ein "echtes" Klonprogramm erzeugt eine 1:1 Kopie, incl. aller leeren Bereiche. Selbstverständlich können auch SWAP-Bereiche und auch diverse andere Partitionstypen geklont werden. So etwas braucht man z.B. in der Forensik, da sich in den leeren Bereichen z.B. die Reste der gelöschten Daten befinden. Ein anderes Anwendungsfeld waren früher die Medien mit Kopierschutz, bei denen dann der Kopierschutz einfach mitkopiert wurde. In 99% der Fälle wendet man heute aber Imageverfahren an, die dann landläufig auch als klonen bezeichnet werden. Die sind ganz unterschiedlich von den technischen Fähigkeiten und auch der Bedienung. Das Klonen erfordert immer einen Fremdstart des Computers. Beim Image würde ich ihn aus meiner Erfahrung zumindest sehr dringend empfehlen. Auch würde ich grundsätzlich zu Fullimages raten, da man ansonsten evtl. auf eine ganze Sammlung von Teilimages zurückgreifen müßte. Ich habe in meinem Berufsleben bereits eine vierstellige Zahl an Rechnern über Klonprogramme bzw. Images installiert. Der Tausch von Festplatten kommt seit etwa 10 Jahren fast gar nicht mehr vor (ist auch eher typisch für SOHO). Meist wird der ganze Rechner getauscht, dann ist ohnehin eine komplette Neuinstallation angesagt, weil Windoof ziemlich zickig ist bei geänderter Hardware. Außerdem ermöglicht auch nur die eine "saubere" Installation auf einen definierten Ausgangszustand. BTW: Seit Win7 benötigt man auch keine händisch geänderte SID mehr. Manchmal muß Windows dann neu aktiviert werden, manchmal auch nicht.
kleiner Admin schrieb: > In 99% der Fälle wendet man heute aber Imageverfahren an, die dann > landläufig auch als klonen bezeichnet werden. Da alle Welt das als Klone bezeichnet, nicht als Image-Kopien, legte ich bisher keinen Wert darauf, diese Haare zu spalten. Gibt es eine formale Definition des Unterschieds? Sonst reden wir bloss aneinander vorbei. > da sich in den leeren Bereichen z.B. die Reste der gelöschten > Daten befinden Es gibt verschiedene Anwendungsfälle. Forensisches Klonen ist nur einer davon. > Das Klonen erfordert immer einen Fremdstart des Computers. Ein Hypervisor kann einen Snapshot der VM duplizieren. Ebenso kann man auf Snapshots im vom Computer genutzten Storage-System zugreifen und Disks kopieren. Beide Verfahren verwenden dafür zwar ein Fremdsystem, sind aber in vollem Galopp des Computers möglich. > Selbstverständlich können auch SWAP-Bereiche und auch diverse > andere Partitionstypen geklont werden. Das war andersrum gemeint. Ein intelligentes Klonprogramm kann optional irrelevante Bereiche weglassen, indem es das Filesystem einer Partition analysiert und darin ungenutzte oder für die Kopie nicht relevante Bereiche erkennt. Für forenische Zwecke ist das natürlich nicht sinnvoll.
:
Bearbeitet durch User
kleiner Admin schrieb: > Der Tausch von > Festplatten kommt seit etwa 10 Jahren fast gar nicht mehr vor Der Tausch von Festplatten kam bei uns noch innerhalb dieses Zeitraums systematisch vor, weil eine SSD als Ersatz einer HDD deutlich billiger war, als ein neuer Rechner. Allerdings wurde dabei i.d.R. kein Inhalt kopiert, sondern das Ergebnis automatisiert neu installiert. > Auch würde ich grundsätzlich zu Fullimages raten, da man ansonsten evtl. > auf eine ganze Sammlung von Teilimages zurückgreifen müßte. Was meinst du damit? Mit den Begriffen Full- vs Teilimage kann ich nicht viel anfangen. > Seit Win7 benötigt man auch keine händisch geänderte SID mehr. Allerdings braucht man für ein paar Zwecke schon noch eine geänderte SID. Nur muss man die nicht händisch ändern, sondern kann das automatisieren.
:
Bearbeitet durch User
> Klon vs. Image Die ersten Verfahren ermöglichten eine sektorgenaue Kopie von Festplatte zu Festplatte (erforderte Festplatten mit gleicher Geometrie). Viele Imageprogramme können auch heute noch sektorgenaue Kopien, aber das wird selten angewandt, denn ursprünglich waren die Festplatten klein, da erfolgte das Klonen in Minuten. Heute sind sie gerne 1000fach so groß, da dauert das einfach zu lange. 😊 > weil eine SSD als Ersatz einer HDD deutlich billiger war Festplattenschäden sind aber GsD kaum noch ein Thema, das war früher anders. Den Wechsel einer Festplatte gegen eine SSD aus Performancegründen nehmen wir meistens nur dann vor, wenn ohnehin das OS gewechselt wird. Dabei gibt es dann auch einen Wechsel von Office und den ganzen Standardprogrammen. Das ist dann aber kein Fall fürs Klonen, sondern eine komplette Neuinstallation (mit Imageverfahren). Und nach 5 Jahren werden bei uns PCs dann eh nur noch im Sonderfall repariert, ansonsten bei jeder Störung einfach durch ein neues Gerät ersetzt. > Full- vs Teilimage Einige Hersteller bewerben da so eine Funktion, die wohl an das klassische Backup angelegt ist. Man kann ein Image erstellen und später dann weitere Images, die dann nur noch die veränderten Teile enthalten. Die müssten dann ggf. sequentiell nacheinander wieder eingespielt werden. Habe ich aber noch nie gemacht, weil ich das für kontraproduktiv halte, denn so erhält man keinen genau definierten Ausgangszustand (da der Rechner ja im Betrieb war). > Allerdings braucht man für ein paar Zwecke schon noch eine geänderte SID. Wofür denn? Seit Win7 machen wir das nicht mehr. Win erkennt die veränderte Hardware und ändert selbstständig die SID. Lediglich der Computername und die IP müssen unbedingt unterschiedlich sein (und natürlich die MAC-Adresse der Netzwerkkarte).
kleiner Admin schrieb: > Die ersten Verfahren ermöglichten eine sektorgenaue Kopie von Festplatte > zu Festplatte (erforderte Festplatten mit gleicher Geometrie). Danke. Ich finde diesen begrifflichen Unterschied tatsächlich so bei einigen Herstellern von Backup-Programmen. Ein Klon ist eine Kopie auf eine andere Disk während ein Image ein File (oder mehrere) auf einem beliebigen Speichermedium ist. Die Forderung zur Geometrie versprüht allerdings den stark modrigen Hauch CHS-adressierter Disks, weil sie bei LBA auf mindestens gleiche Grösse eindampft. Es geht dabei also ausschliesslich um die Art des Zielmediums, nicht um die verwendete Methode. Ob bei der Kopie allerdings exakt 1:1 alles kopiert wird, oder ob ungenutzte Teile eines Filesystems und Swap/Hibernate-Bereiche übersprungen werden, ob der Fokus auf der Disk oder auf den einzelnen Partitionen liegt, das ist von der Art des Zielmediums unabhängig und kann auch bei einer Disk-to-Disk Kopie angewandt werden. In Virtualisierung ist das, was eine VM als Disk sieht, auf der Ebene des Hosts meist ein Image. In SAN-Systemen kann das, was der SAN-Client als Disk/LUN sieht, seitens des Speichersystems ein Image auf einem Filesystem sein. Das obendrein vielleicht keine 1:1 Kopie darstellt, wenn nur genutzte Bereiche der Disk im Image gespeichert werden und gleiche Bereiche verschiedener LUNs/VDisks nur einmal gespeichert werden. Wenn man dann auf Storage-Ebene (VM oder SAN) ein Disk-Image kopiert und die Kopie für einen zweiten Rechner nutzt, dann ist es aus Sicht der Rechner ein klonen, aus Sicht darunter aber imaging. Kommen dann noch Snapshots der Images hinzu... Und man kann ein solcherart auf einem Linux- oder Windows-System erstelltes Imagefile auf diesem System ohne zweite Kopieraktion und ohne Virtualisierung direkt als Filesystem mounten (vgl ISO-File bei CD/DVD). Der Wert dieser in den Tiefen der Geschichte immer mehr verschwindenden Unterscheidung nimmt für mich daher seit langem ab. Die Begriffe "Disk" und "Image" verschwimmen. Weshalb ich - und offenbar nicht nur ich - diese Begriffe nicht mehr so streng unterscheide wie du.
:
Bearbeitet durch User
kleiner Admin schrieb: > Wofür denn? Seit Win7 machen wir das nicht mehr. Beispiel: Ob das nun genau die Rechner-SID ist, habe ich gerade nicht parat. Aber WSUS verwendet eine ID, um die Maschinen zu identifizieren. Und haben wir es gelegentlich erlebt, dass ein Klon (eine Imagekopie ;-) die gleiche ID nutzte wie das Original, obwohl eigentlich die übliche Anpassung des Zielsystems erfolgte.
kleiner Admin schrieb: >> Full- vs Teilimage > Einige Hersteller bewerben da so eine Funktion, die wohl an das > klassische Backup angelegt ist. Man kann ein Image erstellen und später > dann weitere Images, die dann nur noch die veränderten Teile enthalten. Kenne ich unter Begriffen wie incremental image oder so. > Die müssten dann ggf. sequentiell nacheinander wieder eingespielt > werden. Wobei das beschriebene Schema auch ein wenig modrig riecht, weil manche Backup-Systeme längst permanent so arbeiten, ohne dabei aber dieses sequentielle Restore-Verfahren zu erfordern. Wenn der Image-Store eine Datenbank enthält, was sich in welchem Stand wo befindet, funktioniert der Restore direkt, nicht sukzessive. Auch bei Band als Medium für den Inhalt, nur die Datenbank fürs Mapping braucht eine Disk. Obendrein kann man bei solchen Systemen u.U. auch ohne Zwischenschaltung eines Restores direkt per Disk- oder Filesystem-Mount auf den Inhalt des Image-Stores zugreifen, oder parallel zum Restore.
:
Bearbeitet durch User
Ich kenne Clonen eher vom CD "kopieren". Hatte ich aber nicht wirklich gebraucht, Nero war gut genug für meine Bedürfnisse - und meistens sogar besser, z.B. für Audiosachen. Images und Snapshots .. Disketten übertragen aus dem Internet auf den Rechnern zuhause. Musikinstrumente, Atari, dies und das. Gelegentlich auch für Bios-Files. ( https://www.winimage.com/winimage.htm ) Mir geht es auch eher um funktionelle Fragen. Beispielsweise hat gerade das CD/DVD Laufwerk auf dem Windows 8 NB eine Macke. Oblivion startet dann nicht mehr, und eine gute "Kopie" der SpieleCD nützt in diesem Fall nicht viel. Tatsächlich brauche ich keine Kopie, habe die SpieleCD mehrfach. Bundle A, Bundle B, Spielesammlung X, Spielesammlung Y sowas in der Art. Ist meistens auch kein Thema Ersatz nachzukaufen. Nicht immer 1:1, wegen der leicht unterschiedlichen Spieleversionen. Aber unterm Strich fast egal. Für den Atari gab es viele Probleme beim Diskettenkopieren. So wurde viel versucht, und es gab verschiedene Kopierprogramme für verschiedene Probleme.
(prx) A. K. schrieb: > Und haben wir es gelegentlich erlebt, dass ein Klon (eine Imagekopie ;-) > die gleiche ID nutzte wie das Original, obwohl eigentlich die übliche > Anpassung des Zielsystems erfolgte. Dafür gab es doch von Microsoft "Sysprep", den Rechner neutral machen, bevor man das Image erzeugt.
Manfred schrieb: > Dafür gab es doch von Microsoft "Sysprep", den Rechner neutral machen, > bevor man das Image erzeugt. Der übliche Weg in VMware geht über automatische anschliessende Anpassung eines Klons, mit neuem Namen, Netzwerkkonfiguration, Lizenzkey etc. Funktioniert ganz gut, nur bei der Integration in WSUS kommt es ab und zu vor, dass man anschliessend Hand anlegen muss. Sysprep oder etwas in dieser Art ist sicherlich Teil dieses Verfahrens. Diverse Einstellungen werden dabei zurückgesetzt, etwa bei der Taskleiste, was typisch für Sysprep ist. Ein File-Image als Zwischenstation wird dabei nicht verwendet. VMware erzeugt die Kopie direkt aus einem dafür ad hoc angelegten Snapshot der Original-VM. Letzte muss man deshalb dafür auch nicht runterfahren.
:
Bearbeitet durch User
> SID bei WSUS Wie gesagt werden bei uns neue Rechner per Image (gezogen als Goldenes Image) installiert. Ohne Sysprep oder dergleichen. Funktioniert tadellos, auch WSUS scheint die Rechner tatsächlich über ihren Namen(!) anzusprechen. Früher waren die Images mal auf CD, dann auf DVD, heute geht praktisch nur noch eine externe Festplatte, weil die Images selbst bei maximaler Kompression so riesig sind. > Incremental Backup/Image Beim Backup lasse ich mir das ja gerade noch gefallen, weil es manchmal nicht anders geht, aber bei einem Image lieber nicht. Natürlich hat unser Tapesystem auch eine SQL-Datenbank, aber wir haben da mal so ein Incrementelles Backup zurückspielen müssen, das auf 46 Bänder verteilt war. Der ganze Schei$$ hat fast eine Woche gedauert - gut immer noch besser als Datenverlust. Da empfiehlt sich doch gelegentlich ein Fullbackup... > Klon als sektorgenaue Kopie Der Hauptvorteil des Clonens ist, daß es absolut unabhängig vom Betriebssystem oder dem Filesystem funktioniert. Auslassen von freien Bereichen erfordert immer, daß das Imageprogramm wissen sollte, was es da tut. bei gängigen OS sicher kein Problem, aber wenn man die verteckte Kopie einer Novell Netware Partition kopieren möchte... Ehrlich gesagt weiß ich gar nicht, ob man bei einer SSD überhaupt noch eine sektorgenaue Kopie machen kann, weil da schließlich noch ein Controller dazwischen sitzt, der die Pages managed. Aber für das OS sieht das dann möglicherweise wie eine sektorgenaue Kopie aus. OT: Ich habe das jetzt auch schon jahrelang nicht mehr machen müssen. Da ging es auch nicht um Spiele, sondern um Steuerungsrechner. Manche Hersteller treiben da die tollsten Sachen als Kopierschutz. Ein Gerät hatte z.B. einen erzeugten Schlüssel aus IP-Adresse und Rechnernamen (und was weiß ich, woraus sonst noch) - ein Umbenennen des Rechners kostete 5.000€ für die Installation eines neuen Schlüssels; in dem Fall "lohnt sich" schon eine sektorgenaue Kopie auf einer Ersatzfestplatte. 😊 Wir hatten auch schon mal den Fall, daß der Schlüssel an die MAC der Netzwerkkarte gebunden war; damals waren die Netzwerkkarten noch Steckkarten, so daß man immerhin den Rest des Rechners auswechseln konnte.
kleiner Admin schrieb: > Ehrlich gesagt weiß ich gar nicht, ob man bei einer SSD überhaupt noch > eine sektorgenaue Kopie machen kann, weil da schließlich noch ein > Controller dazwischen sitzt, der die Pages managed. Aber für das OS > sieht das dann möglicherweise wie eine sektorgenaue Kopie aus. Aus Sicht der physikalischen Blöcke auf den Flash-Modulen ist eine exakte Kopie effektiv unmöglich. Aus Sicht der logischen über das Interface zum Controller adressierten Blöcke ist eine exakte Kopie kein Problem. Block 1 auf Block 1, Block 9999 auf Block 9999, wo immer die in den Flash-Chips gerade liegen - das ändert sich sowieso bei jedem Schreibvorgang. Einzig die logische Sicht zählt. Das ist aber nur ein weiterer Teil der von mir oben beschriebenen Trennung von logischer Betrachtung (VM-Disk, SAN-LUN) und dem darunter liegenden Layer (Image-File der VM, Image-File einer NAS). Das kann ja dann auch noch ein paar Ebenen weiter nach unten gehen, wenn die Files der NAS mit dem LUN-Image wiederum auf SSDs liegen. Da sind so viele translation layer dazwischen, dass jedwede Vorstellung von 1:1 Abbildungen vollkommen sinnlos wird. Manche SAN-Systeme haben vorneweg einen SAN-Controller, der seinen realen Storage wiederum über mehrere sekundäre SAN-Storage-Systeme ggf anderer Hersteller verteilt, ohne dass dies auf der primären Seite irgendwie sichtbar wäre.
:
Bearbeitet durch User
kleiner Admin schrieb: > Wie gesagt werden bei uns neue Rechner per Image (gezogen als Goldenes > Image) installiert. Bei uns werden PCs per Netzboot vollständig automatisiert installiert, Windows und Anwendungen. Keinerlei Images. Zur Neuinstallation eines bestehenden PCs wird die MAC-Adresse des PCs im entsprechenden System eingetragen, gestartet, und gut eine Stunde danach ist er fertig. Bei einem neuen Anwender kommt natürlich noch die Auswahl der Anwendungen hinzu. Die können recht verschieden sein, je nach Einsatzbereich. Was ich oben über Klone per VMware beschrieb, bezieht sich auf Server und einige Linux-VMs für Anwender.
kleiner Admin schrieb: > Natürlich hat unser Tapesystem auch eine SQL-Datenbank, aber wir haben > da mal so ein Incrementelles Backup zurückspielen müssen, das auf 46 > Bänder verteilt war. Der ganze Schei$$ hat fast eine Woche gedauert Yep. Aber bei heutigen Disk-Kapazitäten sind Bänder - soweit überhaupt noch vorhanden - eher als Sekundärspeicher relevant. Den letzten Stand der Sicherung bewahrt man tunlichst auf Disk auf, um schnell ranzukommen. Sowas im Katastrophenfall von Band holen zu müssen, ist kaum noch machbar. Da schaut man eher, dass man den Backup-Storage anderweitig aus der kritischen Zone kriegt, nicht mehr über herumgeschubste Bänder. Mittlerweile kann das z.B. auch die Amazon S3 Technik in der Cloud sein.
:
Bearbeitet durch User
kleiner Admin schrieb: > Wir hatten auch schon mal den Fall, daß der Schlüssel an die MAC der > Netzwerkkarte gebunden war Diesen Mist kenne ich nur zu gut. Beispielsweise USB-Dongles für VMs. Dafür gibt es zwar Lösungen via Netz, aber eine hochverfügbare Umgebung zu haben, die sogar dann noch funktioniert, wenn das Gebäude mit einem der Serverräume geflutet wird, nützt nichts, wenn der paranoide Anbieter einer Lösung partout nur einen einzigen Dongle liefert - mit dem Ersatz notfalls per Taxi quer durch die Republik. Ziemlich gaga. Aber mittlerweile haben auch jene Mitarbeiter das kapiert, die die Lösungen aussuchen. Mancher merkt es erst, wenn es hektisch wird.
:
Bearbeitet durch User
kleiner Admin schrieb: > Der ganze Schei$$ hat fast eine Woche gedauert Herrlich. Aber wie darf man sich das vorstellen (den technischen Teil)? Früher konnte man mit WinZip größere Dateien (meist MP3 oder Treiber, Linux/Gcc/MuLinux auch mal) auf mehrere Disketten verteilt speichern. Daumen drücken, dass auch alle Disketten mitmachen. Das war nicht immer gegeben, und falls nicht, hatte man zusätzliches Chaos mit Datenschrott. Spaß auch mit Datenkassetten zum Speichern von Synthesizer-Patches oder Samples. Selbst wenn man diese Piepsfolgen gesampelt hatte (TX16W z.B.) und so etwas mehr Kontrolle über Lautstärke und Geschwindigkeit der Piepser da war - eine Macherei mit Herumprobieren (vor allem Lautstärke) war das doch immer wieder. Noch viel früher: Datenbänder (Personalverwaltung Kohlebergbau) im Safe mit Nummernschloss gesichert. Der Zugang war längst verloren bzw. aufgegeben. So hieß es jedenfalls offiziell, und ich kann mein Glück ruhig versuchen. (Der Raum, in dem der Safe stand, war gleichzeitig der Pausenraum der Elektriker (Hausinstallationsstuff) (bei denen ich ein paar Wochen lang Schule-bedingtes Praktikum machte)).
rbx schrieb: > Aber wie darf man sich das vorstellen (den technischen Teil)? Mit Bandroboter: Restore anstossen und w-a-r-t-e-n. Den Rest verhandeln Backup-Software und Roboter untereinander.
:
Bearbeitet durch User
rbx schrieb: > Herrlich. Aber wie darf man sich das vorstellen (den technischen Teil)? Wir haben zwei Libraries, die jeweils 60 LTO-bänder aufnehmen können. Diese werden jeweils durch einen "Laderoboter" bedient, aber die Bestückung der Magazine erfolgt von Hand. Nun sind aber natürlich nur ein paar Slots frei, z.B. 10 Stück. Die Software sucht für den Restore nach den Bändern, die benötigt werden in der Datenbank. Der Job startet, es werden Bänder angefordert, die nicht im Magazin sind. Jetzt kann man die ersten 10 einlegen (wenn man denn eine ausgedruckte Liste hat, welcher Job auf welchem Band ist, sonst muß man in der Datenbank mit einer nervigen Filteroberfläche herumsuchen), dann muß eine Inventarisierung durchgeführt werden, damit die Library weiß, was in welchem Slot ist (die Bänder haben einen Barcode). Dann kann man dem Job sagen, mache gefälligst weiter. Warten, warten, irgendwann braucht der Job ein Band, das nicht im Magazin ist, dann muß man welche entnehmen und die gewünschten einlegen, inventarisieren, fortsetzen. Das Spielchen kann sich dann wiederholen bis der Job abgearbeitet ist. Das ist natürlich nichts für absolut lebenswichtige Daten, die haben wir dann z.B. auch auf Disk, aber zur Langzeitspeicherung ist das nicht verkehrt. Außerdem ist der Preis pro TB bei den LTO-bändern relativ moderat. Kleinere Sachen kann man natürlich auch rotierend auf Band sichern. Z.B. am Monatsanfang eine neues Band nehmen, dann eine Vollsicherung und jeden Tag eine Differentialsicherung. Und nach 5 Monaten wieder das erste Band nehmen. Aus der Sache haben wir gelernt, daß auf einem Band möglichst immer nur ein "Volume" gespeichert wird, damit man ggf. nicht auf so viele Bänder zurückgreifen muß. Außerdem verwenden wir die meisten Bänder für die großen Volumes tatsächlich nur noch einmal, da man die User einfach nicht dazu bekommt, vernünftige Vorgaben zu machen, hebt man besser den ganzen Müll auf. (Ja, wir sichern tatsächlich noch Installationsdateien für den Netscape Navigator 4. Es ist gar nicht gut für meinen Blutdruck, das zu genau wissen zu wollen. 🙄 ) Das ist etwas tricky, weil die Software natürlich stets selbst bestimmen möchte, was sie wo speichert; die Software muß also etwas ausgetrickst werden. 🙄
(prx) A. K. schrieb: > Restore anstossen und w-a-r-t-e-n. Ah, ach so. Danke. Das war beim Commodore 16 auch recht zuverlässig: Play-Taste drücken und warten, bis der Programmbildschirm erscheint. Wie lange dauert eigentlich heute so ein Snapshot? Früher musste man für Größen bei ab 3-stelliger GB Zahl schon ein paar Stunden warten. Vor diesem Hintergrund mache ich doch lieber gezielte Ordner-Kopien. und das ist auch nochmal ein wenig OT: Sampler vs Sythesizer. Für Synths braucht man nicht so viel Speicher, und kann trotzdem viel mit machen. Unser "Gedächtnis" läuft ganz ähnlich ab. Bei einem Uni-Vortrag meinte ich mal: "ganz ähnlich wie Malen nach Zahlen" Verdutzte Blicke aus der Zuhörermenge: "Was ist Malen nach Zahlen?" Das hatte mich verdutzt, das hatte ich in meinen Vortragsvorbereitungen nicht bedacht. Ich dachte, das Prinzip war gut bekannt, und so leicht verstanden. Da hatte ich mich aber geirrt. Man könnte auch sagen, so ähnlich wie bei Synthesizern vs Samplern. Man nimmt normalerweise keinen kompletten "Wellensalat" auf, sondern eher nur ein paar Eckpunkte und macht daraus selber "Wellensalat". ;) (ist nur eine Theorie, aber eine recht gut belegte bzw. untersuchte) Eine weitere interessante Theorie ist das "Blitzlicht-Gedächtnis". Da könnte man aber vermuten, dass die ständige Wiederholung der Bilder, und das ständige Neuerzählen für eine gute Menge an erinnerbaren Einzelheiten sorgt. Ein Abzweig dieser Geschichte ist dann noch Gedächtnis und Emotion. Da könnte man noch eine ganze Menge zu erzählen - so ganz grob kann man sagen, ist beides nicht ganz unabhängig voneinander.
rbx schrieb: > Wie lange dauert eigentlich heute so ein Snapshot? Früher musste man für > Größen bei ab 3-stelliger GB Zahl schon ein paar Stunden warten. Kommt drauf an was du damit wirklich meinst und wo du ihn anlegst. Ein Snapshot ist zunächst keine Sicherung, weil auf dem gleichen Medium wie das Original. * CoW Filesysteme Netapp/ZFS/btrfs: Sekunden. * VMware inaktive VM: sofort * VMware aktive VM: unter 1 Minute bis mehrere Minuten, je nachdem, ob mit oder ohne RAM-Stand und welche Art der Transaktionssicherung.
kleiner Admin schrieb: > (wenn man denn > eine ausgedruckte Liste hat, welcher Job auf welchem Band ist, sonst muß > man in der Datenbank mit einer nervigen Filteroberfläche herumsuchen) Danke auch dir für ausführlicheren Erklärungen. Im Alltagsleben auch nicht so unbekannt: Videokassetten beschriften oder nicht? Früher wusste ich noch, welche Aufnahme auf welcher Videokassette ist. Gelegentliche Suche gab es auch - aber irgendwann später hatte ich auf einmal alle Hinweise vergessen. Die ein oder andere Erinnerung an den Inhalt selber ist noch vorhanden. Schwierig jetzt nur die Wiederholung auf Band bzw. die zugehörige Videokassette finden. Ein wenig Ersatzbefriedigung ist YT + altes Buch bzw. Lexikon von '77 mit der Vorstellung verschiedener Musikgruppen (Disco/Ilja Richter Sonderband o.ä.) - jetzt kann man die endlich mal hören :)
rbx schrieb: > Vor diesem Hintergrund mache ich doch lieber gezielte Ordner-Kopien. Snapshots auf Speichersystemen wie Netapp werden problemlos z.B. stündlich automatisch angelegt und wieder weggeräumt, ohne jedwede Auswirkung auf den laufenden Betrieb. Die Kapazität des Volumes spielt dabei keine Rolle, also ob 5 GB oder 5 TB. Anders als bei Ordnerkopien kosten dabei nur zwischenzeitlich geänderte Daten neuen Platz, und auch darin nur jene Teile grosser Files, die sich änderten. Auf alte Stände lässt sich im Kontextmenu des Windows Explorers direkt zugreifen, über den gleichen Menupunkt wie bei den Wiederherstellungspunkten in Windows selbst (ein damit verwandtes Verfahren). Solche Snapshots ersetzen keine Desaster-Backups, können aber Teil solcher Backups sein, um konsistente Zustände zu einem exakten Zeitpunkt sicherzustellen. In dem also über das gesamte Volume alles drin ist, was vorher geschah, und nichts, was später geschah. Inkrementelle Backups können sie nutzen, indem jeweils die Differenz zweier Snapshots gesichert wird. Die ergibt sich aus der Implementierung, erfordert also keine aufwändige Suche.
:
Bearbeitet durch User
rbx schrieb: > Im Alltagsleben auch nicht so unbekannt: Videokassetten beschriften oder > nicht? In automatisierten Bandsystemen werden Bänder verwendet, die mit einer maschinenlesbaren ID versehen sind, in Form eines Barcodes.
kleiner Admin schrieb: > Das ist etwas tricky, weil die Software natürlich stets selbst bestimmen > möchte, was sie wo speichert; die Software muß also etwas ausgetrickst > werden. In manchen Backupsystemen lässt sich konfigurieren, ob und bis zu welchem Grad zusammenhängende Daten auch zusammenhängend gespeichert werden. Das geht vom einen Extrem eines vom System völlig frei verwalteten Bandpools bis zur Minimierung der Anzahl Bänder, auf die sich ein gesichertes Volume verstreut. Was man dabei wählt, hängt vom verfolgten Ziel ab. Geht es um möglichst schnelle Recovery verlorener Volumes, wird man Letzteres wählen. Für Archivdaten, auf die man nur selektiv zugreift, kann Ersteres sinnvoller sein. Es können dabei auch Staging-Verfahren zum Einsatz kommen. D.h. die akute Sicherung landet zunächst in einem Disk-Pool, dessen Inhalt erst danach automatisch auf Band verschoben wird. Das nutzt die Laufwerke effizienter und Backup-Sessions sind nicht auf die Anzahl Bandlaufwerke begrenzt. Ggf landen die Backups parallel in einem weiteren Disk-Pool, der nur den letzten Stand jedes auf dem gesicherten System noch vorhandenen Objektes enthält. Damit geht der Restore des letzten Standes recht flott, weil man keine Bänder benötigt.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Snapshots auf Speichersystemen wie Netapp werden problemlos z.B. > stündlich automatisch angelegt und wieder weggeräumt, ohne jedwede > Auswirkung auf den laufenden Betrieb. > [...] Auf alte Stände lässt sich im Kontextmenu des Windows > Explorers direkt zugreifen, über den gleichen Menupunkt wie bei den > Wiederherstellungspunkten in Windows selbst Wer das selber nachbauen will: btrfs, "snapper" zum Anlegen/Aufräumen der stündlichen/täglichen/wöchentlichen/jährlichen Snapshots, samba mit "vfs objects = btrfs snapper ..."
Εrnst B. schrieb: > Wer das selber nachbauen will: Bei Suse auf Grundlage von btrfs ist diese Möglichkeit bereits von vorneweg dabei und wird von Suses System-Management Tool auch unterstützt. Soweit ich mich erinnere bis zur Möglichkeit, einen alten Stand zu booten. Bei Ubuntus ZFS Option war das zumindest zu jenem Zeitpunkt, zu dem ich einen Blick darauf war, noch nicht so konsequent integriert.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bei Suse Kann ich mir vorstellen, snapper ist ja auch ein SuSE-Projekt. Ersetzt zwar kein Backup, aber der Samba Snapshot-Zugriff für Windows-Clients ist echt Gold wert. Was der an "Hilfe, ich habe meine Datei überschrieben/gelöscht/verloren"-Anfragen an den Admin spart ...
Wer sich drüber wundert, dass das nichts zu kosten scheint: Der Schlüssel dazu sind Copy-on-Write Filesysteme wie WAFL(Netapp), ZFS und btrfs. Auf diese Funktion bezogen lassen die sich quick-and-dirty so beschreiben: Deren grundlegendes Arbeitsprinzip besteht darin, alle zig Sekunden einen Snapshot anzulegen, und niemals Daten zu überschreiben, die sich in einem noch bestehenden Snapshot befinden, sondern sie stets in unbenutzten Bereich zu schreiben. Metadaten wie Directories und Blockmaps inklusive. Normalerweise werden diese impliziten Snapshots gleich wieder weggeräumt, sobald der nächste definitiv vollständig auf Disk ist. Aber wenn man einen länger braucht, dann halt nicht. Positiv: Jeder solche Stand ist vollständig point-in-time konsistent, ohne dass man dazu irgendwelche Vorkehrungen traditioneller Filesysteme implementieren muss, wie Journalling (NTFS, ext4). Was bis zum letzten Snapshot im Filesystem enthalten war, ist im Fall eines Stromausfalls exakt so vorhanden, was danach kam ist vollständig weg. Negativ: Selektiv geschriebene Files wie Datenbank-Container fragmentieren höllisch, weil mit der Zeit das, was einstmals sequentiell auf Disk stand, sich nun kunterbunt über die Disk verteilt. In Zeiten von HDDs konnte sich das auf die Performance von full table scans sehr markant auswirken. Aber mit dem Siegeszug der SSDs ist das irrelevant geworden.
:
Bearbeitet durch User
(prx) A. K. schrieb: > und niemals Daten zu überschreiben, die sich > in einem noch bestehenden Snapshot befinden, sondern sie stets in > unbenutzten Bereich zu schreiben. Um den Bogen zurück zu Backups zu spannen: Dadurch kann das Dateisystem sehr leicht ermitteln welche Blöcke sich zwischen zwei Snapshots verändert haben. Die lassen sich dann exportieren ("btrfs/zfs send") & archivieren, oder auch direkt auf eine Off-Site-Maschine übertragen und dort wieder in ein Dateisystem importieren ("btrfs/zfs receive"). Dort entsteht dann eine Backup-Kopie incl. eigener Versionshistorie...
(prx) A. K. schrieb: > In manchen Backupsystemen lässt sich konfigurieren, ob und bis zu > welchem Grad zusammenhängende Daten auch zusammenhängend gespeichert > werden. Das geht vom einen Extrem eines vom System völlig frei > verwalteten Bandpools bis zur Minimierung der Anzahl Bänder, auf die > sich ein gesichertes Volume verstreut. > > Was man dabei wählt, hängt vom verfolgten Ziel ab. Geht es um möglichst > schnelle Recovery verlorener Volumes, wird man Letzteres wählen. Für > Archivdaten, auf die man nur selektiv zugreift, kann Ersteres sinnvoller > sein. Kann man das noch etwas näher betrachten? Ich denke z.B. an die Bedienung von den Samplern Yamaha TX16W vs Emu Emax2. Beim TX16w waren die Wellenformen in einem Pool, und man konnte sie so vielfältig bearbeiten, kombinieren, Klänge austauschen usw. Nachbearbeitung z.B. mit Filtern oder LFO wurden später gemacht. Die Filter selber waren auch spannend, die waren keine einfachen Filter, sondern es gab verschiedene Tabellen mit unterschiedlichen Kurven zum Ausprobieren. Ein Filter-Pool. Freiheit der Digitaltechnik gewissermaßen.. Wenn man die Nachbearbeitungen soweit fertig hatte, kamen die Multisample-Einstellungen, Tastaturzuordungen, Midikanäle usw. Vielen war die fragmentierte, mehr experimentelle Bedienung zu kompliziert. Später gab es noch ein anderes Betriebssystem mit anderen Stärken, wie Resampling, Komprimierung, besser klingender Filter (statt nur gut aussehen) und auch eine einfachere Bedienung. Aber dann hatte man auch schon Probleme mit der Datensicherung, wegen der zwei unterschiedlichen Betriebssysteme. Beim Emax2 wurde man beim Samplen schon genötigt, ein Multisample + passende Nachbearbeitungen zu erstellen. Einen Wellenpool gab es in diesem Sinne nicht. Die Nachbearbeitungen waren nicht so zwingend, aber die schwebten gewissermaßen schon über den Multisamples drüber und Patchbezogen. Man brauchte nicht extra ein Menü für Nachbearbeitungen aufrufen, sondern im "Patch" nur einen Knopf drücken, Wert einstellen, fertig. Prinzipiell eine sehr angenehme, und im musikalischen Sinne förderliche Bedienung. Von der Indexierung her denke ich an das Open Directory - wie schwierig manchmal die Diskussionen waren, was wohin "gehört". Für viele Links war erstmal wichtig, die reinzuschaufeln, bevor man irgendeine Ordnungsvorstellung darauf anwendet. Unabhängig davon sehr nützlich war immer die alphabetische Sortierung. Da brauchte man auch nicht soviel streiten. Was ich meine ist: Wenn die Software die "Ordnung" der Sicherungsspeicherung auf Bändern vorgibt: Da könnte man schauen, ob die Ordnung angemessen ist. Manchmal kann man sich aber auch nur wundern über gewisse Automatismen. Die Haskell-Plattform hatte sich im Windows TMP (oder Temp?)-Ordner ausgepackt. Das ging aber nicht, meine Windows (ME)-Partition war zu klein. Nach dem Umleiten des Auspack-Ziels kam dann die Meldung (im übertragenen Sinne): Windows zu alt.. Die Watcom-Entwicklungsumgebung ließ sich viel unproblematischer Installieren. Aber wie bei Haskell: tonnenweise Literatur ;)
Εrnst B. schrieb: > Dort entsteht dann eine Backup-Kopie incl. eigener Versionshistorie... Yep. Man wird dann auf dem teuren Primärsystem nur wenige Stände für akute Anfragen bevorraten, während das billige Sekundärsystem auf viele Monate oder Jahre zurückblickt.
:
Bearbeitet durch User
> Snapshots Dabei muß man aber immer bedenken, daß das keine Backups sind. Ein Backup ist immer eine Kopie, bei einem Snapshot werden jedoch nur die Daten gespeichert, die sich geändert haben. Geht die unveränderte Originaldatei verloren, dann fehlt die auch in allen Snapshots. Unser Backupprogramm arbeitet auch mit Snapshots/Shadow Copy, um zu einem definierten Zeitpunkt konsistente Daten zu haben. Anders ginge das auch kaum noch, da manche Datensicherungsjobs durchaus Stunden/Tage dauern können. Wir benutzen die Tapes auch zur Aufbewahrung von Originaldaten, d.h. nach der Archivierung werden die Originale von den Festplatten gelöscht. Womit ich jedoch noch nie experimentiert habe ist das LTO-Filesystem. Man kann die Bänder so formatieren, daß sie mit einem wahlfreien Zugriff genutzt werden können, also beliebiges/selektives Lesen und Schreiben. Das andauernde Spulen dürfte für die Tapes und die Laufwerke ziemlich belastend sein. Und im Zeitalter von Festplatten im TB Bereich erscheint das auch nicht wirklich reizvoll. Eine RS6000 habe ich einmal spaßeshalber von einem Band aus gebootet (die Maschine hatte noch kein CD-Laufwerk). Hat gefühlt mindestens eine Stunde gedauert bis der Unix Prompt erschienen ist. Hat aber funktioniert. rbx schrieb: > Was ich meine ist: Wenn die Software die "Ordnung" der > Sicherungsspeicherung auf Bändern vorgibt: > Da könnte man schauen, ob die Ordnung angemessen ist. Auch die IT unterliegt Modeerscheinungen. Unsere Backupsoftware will eigentlich, daß man Pools an Speichermedien definiert auf der Basis wie lange die Daten aufbewahrt werden müssen. Klingt erst einmal nicht schlecht, aber das erste Problem ist schon einmal, daß eigentlich nur die Nutzer das wirklich beurteilen könnten - meistens dazu aber gar nicht in der Lage sind oder schlicht keine Lust dazu haben. Außerdem kann das dazu führen, daß das tägliche Zuwachsbackup jeden Tag auf einem anderen Band landet, so daß nur noch die Datenbank weiß, was wo gespeichert ist. Aber was ist, wenn die Datenbank kaputt geht. Klar kann man die neu aufbauen durch Einlesen sämtlicher Bänder, aber das würde im Falle des Falles eben ewig dauern. Beispiel 1 Band = 3h, 200 Bänder = 600h, das wären dann 25 Tage. Wir haben uns daher für die Lösung entschieden: Datenbestand A auf Pool A, Datenbestand B auf Pool B, usw. Ist vielleicht nicht optimal, was die Kapazitätsnutzung und die Sicherungsgeschwindigkeit angeht, aber dafür weiß man, was auf den Bändern ist.
kleiner Admin schrieb: > bei einem Snapshot werden jedoch nur die Daten gespeichert, die sich > geändert haben. Geht die unveränderte Originaldatei verloren, dann fehlt > die auch in allen Snapshots. Nein. Ein Snapshot besteht aus allen Daten, die zum entsprechenden Zeitpunkt gültig waren. Egal ob kurz vorher geändert oder schon uralt. Ein Snapshot ist keine Differenz zu vorherigen Ständen. Dies gilt für die erwähnten Filesysteme und für Microsofts Shadow Copies im NTFS. Nur die jeweilige Implementierung differiert. Ich frage mich daher, von was für Snapshots du gerade redest.
:
Bearbeitet durch User
PS: Was man in der Wikipedia zu copy-on-write in Filesystemen findet, ist mindestens problematisch und in diesem Fall schlichtweg falsch: https://en.wikipedia.org/wiki/Copy-on-write#In_computer_storage Siehe auch Kommentar dazu: https://en.wikipedia.org/wiki/Talk:Copy-on-write#Alternate_meaning
:
Bearbeitet durch User
Hallo, rbx schrieb: > Wie lange dauert eigentlich heute so ein Snapshot? Früher musste man für > Größen bei ab 3-stelliger GB Zahl schon ein paar Stunden warten. da ich, wiel wohl auch der TO, kein Datenzentrum zuhause habe: Image der HD wo mein Win10 drauf ist: Quelle: eNVME 1TB WDS100T3X0C System 660GB / 260GB frei "Arduino"-Kram 270GB / 180GB frei Wiederherstellung, UEFI-Kram / was Win10 so anlegt. Ziel: externe USB3-HD ST4000DM000 Image mit Macrium Reflect Free 8.0 "nebenbei" erstellt (webserven, Sciptgeschichten, die auf anderer HD liegen usw.) Laufzeit 20-25min. erzeugte Dateigröße ca. 185GB. Eine 2. SATA SSD mit Daten wird seltener genauso gesichert, Dateigröße ca. 350GB. 2 Partitionen einer 4TB-HD mit "Lagerdaten, wo sich sehr wenig ändert, wird mit RoboCopy-Scripten gesichert. Zumindest ist mir in den letzen 20 Jahren noch nichts wichtiges abhanden gekommen. Gerade geschaut: die Sicherungen meines damaligen Amiga 4000 von Dez. 2002 liegen als .lha auch noch auf der Lager-HD. Genauso wie irgendwann mal geretteter C64-Kram incl. Schaltpläne im Pagefox-Format incl. der nötigen Zutaten für einen Emulator oder einen echten C64. Den gibt es hier auch noch... Gruß aus Berlin Michael
(prx) A. K. schrieb: > Ein Snapshot ist keine Differenz zu vorherigen Ständen. > > Dies gilt für die erwähnten Filesysteme und für Microsofts Shadow Copies > im NTFS. Ganz abgesehen davon das der Thread mal wieder vollkommen entgleist ist: Um vollständige Kopien zu sein, sind NTFS-Schattenkopien viel zu schnell und viel zu klein. Wie könnte man sonst 50 Schattenkopien auf einer Festplatte haben, die mehr als 2% voll ist? Wie andere Dateisystem das machen weiß ich nicht, aber VSS ist definitiv ein Differenzsystem.
Jens M. schrieb: > Um vollständige Kopien zu sein, sind NTFS-Schattenkopien viel zu schnell > und viel zu klein. Richtig. Es sind keine vollständigen Kopien. Snapshots sind keine Desaster-Backups, sie selbst eignen sich nicht zur Wiederherstellung eines zerstörten Volumes. Zur Wiederherstellung von Dateien und Dateibäumen, die ein Anwender versifft hat, sind sie hingegen ideal. Das ist Tagesgeschäft in Unternehmen. Das spricht eine häufig auftretende Begriffsverwirrung an. Es gibt zwei verschiedene Verständnisse des "Backup" Begriffs. (1) Vollständige Wiederherstellung im Desaster-Fall und (2) selektive Wiederherstellung einzelner Daten. Das muss nicht unbedingt durch ein einziges Verfahren implementiert sein. Für Wiederherstellung von Volumes und Speichersystemen muss man andere Methoden verwenden. Die Differenz zweier Snapshots kann aber, wie oben beschrieben, dabei helfen, mit wenig Aufwand auf einem Zweitsystem (vorzugsweise an einem anderen Ort) eine inkrementell mitlaufende vollständige Kopie auf Disk(s) vorzuhalten. > Wie könnte man sonst 50 Schattenkopien auf einer Festplatte haben, die > mehr als 2% voll ist? Unveränderte Daten werden nicht kopiert. Es wird nur mitgezählt, wie viele Snapshots auf die gleichen Daten verweisen. Kopien von Blöcken (nicht Files) entstehen erst, wenn sie verändert werden.
:
Bearbeitet durch User
Ja, das weiß ich. Das bezog sich auf deine Aussage oben (prx) A. K. schrieb: > Ein Snapshot ist keine Differenz zu vorherigen Ständen. Genau das ist er eben wohl, wenn es sich um einen VSS-Snapshot handelt. Der Snapshot selbst beinhaltet keinen kompletten Stand, sondern nur die Unterschiede zum vorherigen.
Und wenn man sich den totalen Kick geben will, dann macht man "Deduplizierung", d.h. es gibt jede Datei nur noch einmal im Original und der Rest sind Verweise. So etwas gibt es auch für Backups: da muß man dann aber tiefes Vertrauen in die Technik haben. 😉 Michael U. schrieb: > Laufzeit 20-25min. erzeugte Dateigröße Das entspricht auch ungefähr der Laufzeit für die Images. Zwar werden die Medien schneller, aber dafür wird auch der Datenberg größer. Ausnahme sind z.B. ganz alte Rechner, die noch kein USB3 haben. Da dauert das Aufspielen eines Images schon mal 1,5 Stunden... Aber immer noch besser als das ganze OS und alle Programme von Hand zu installieren. 😁
kleiner Admin schrieb: > Und wenn man sich den totalen Kick geben will, dann macht man > "Deduplizierung", d.h. es gibt jede Datei nur noch einmal im Original > und der Rest sind Verweise. > So etwas gibt es auch für Backups: da muß man dann aber tiefes Vertrauen > in die Technik haben. DAS ist interessant - da fällt mir eine ganze Menge zu ein. Hoffentlich vergesse ich beim Schreiben des Artikels nicht, was ich schreiben wollte. Hier und da gibt es wohl begriffsbedingte Missverständnisse. Auf jeden Fall hatte ich mal mit dem Programm Drive Snapshot meine Windows Me Installation auf einer 20 GB Festplatte gesichert. Für ME hatte ich experimentell nur eine Partition von 1 GB ausprobiert. Tatsächlich ist 1 GB etwas zu knapp, aber man konnte später einige Sachen löschen um wieder mehr Platz für dies und das zu haben. Die anderen Partitionen für Datengrab, Backups, Usb, CD(DVD)-Brennen und sonst noch. Mainboard von 2001. Gesichert hatte ich auf eine Usb-Festplatte, 1TB. http://www.drivesnapshot.de/de/index.htm Dauer: 6-8 Stunden. Das brennen der "Backup"-Partition(en) dauerte meistens nur ein paar Minuten. Die Festplatte meines 2008 ersten NBs war, bzw. ist 250 GB groß, die hatte ich zweimal mit Clonezilla auf die Usb-Festplatte "kopiert". Das dauerte wohl auch zwei drei Stunden, oder länger. So, jetzt zurück zu den Links: Die Sicherungen von dem NB sind für mich nicht wirklich ideal, weil ich die nicht so oft mache, und die älteren Sicherung durch Veränderung des Inhalts auf dem aktuellen PCs schnell sinnloser werden. Man müsste eigentlich täglich sichern, und ein paar Tage puffern. (mache ich aber nicht) (die Uni schon, die hatte 14 Tage Puffer) Zusätzlich habe ich viele Original-CDs, die bei der Restaurierung nach Notfällen helfen. Bei meinen Diablo2-Charakteren Online (Battle.net) gibt es keine Offline-Speicherung der Charaktere, außer durch Hacks. Da ich aber oft mehrere Charaktere und sogenannte "Mulis", Platzhalter für Items, pro Ladderrun nutzte fand ich Bilder, also Screenshots sehr hilfreich. Welcher Charakter (auf welchem Konto) hatte jetzt die Schuhe aus dem Sigon-Set? Manchmal hatte ich extra einen Charakter für diese Sigon-Rüstung oder auch nur für diese Art von im Spiel grünen Set-Items. Screenshots können sehr hilfreich sein, weil man bei Neuinstallationen verschiedenen Zusammenhänge aus dem Urzustand leicht vergessen kann. Hier würde nicht nur ein Sceenshot helfen, sondern auch eine gelistete, also ausdruckbare Ausgabe/Übericht des Inhalts der Festplatte und aller Unterordner. Bei den Bändern könnte man - wenn die nicht so teuer sind - eine experimentelle Reihe versuchen. Eine Datenbank mit vollem Zugriff auf alle Inhalte, und ihre Sicherung. Eine Ausgabe zur Übersicht der Inhalte auf Papier oder einer anderen Liste - und natürlich äußere Ressourcen (Original CDs, Internet, Usb-Stick-Turnschuhnetzwerk, Notizbuch und andere Sachen) Die Vergessenskurven sind recht linear (schräg nach unten). Aber es gibt sie. Was ist merkwürdig? Früher (sehr viel früher) war Gedächtniskunst beliebt. Merkwürdig: https://www.amazon.de/Art-Memory-Frances-Yates/dp/1847922929
Jens M. schrieb: > Genau das ist er eben wohl, wenn es sich um einen VSS-Snapshot handelt. > Der Snapshot selbst beinhaltet keinen kompletten Stand, sondern nur die > Unterschiede zum vorherigen. Wobei Snapshot und Original dieser NTFS Shadow Copies für mich eine zusammengehörige Einheit darstellen und der Snapshot keine vom Volume sinnvoll lösbare Komponente darstellt. Unbekannt war mir bis dato, dass man bei NTFS für den Snapshot-Space auch ein separates Medium verwenden kann. Mit diesem alleine kann man wirklich nichts anfangen. Dass Snapshots keine Desaster-Backups darstellen, war schon geklärt. Das ist nicht deren Sinn. Die Diskussion bezog sich hierauf: kleiner Admin schrieb: > Geht die unveränderte > Originaldatei verloren, dann fehlt die auch in allen Snapshots.
:
Bearbeitet durch User
rbx schrieb: > Das brennen der "Backup"-Partition(en) dauerte meistens nur ein paar > Minuten. Ein Image ist für eine Datensicherung sicherlich keine ganz optimale Lösung, aber eine relativ einfache. Es wird einfach ein aktueller Zustand komplett gesichert; nicht mehr und nicht weniger. Wenn man das z.B. einmal pro Halbjahr macht, dann hat man immer ein relativ aktuelles System in Reserve (plus noch ein paar ältere). Allerdings sollte dann das Image immer auf einem entnehmbaren Datenträger (heute wohl meist externe Platte oder vielleicht ein großer Stick) liegen. Sehr gut geeignet ist das Verfahren, wenn man das Betriebssystem öfter einmal neu installieren muß. Es gab mal eine Studie, daß in einem komplett installierten und konfigurierten(!) Arbeitsplatz etwa 200 Arbeitsstunden stecken. Da sind die 20 Minuten für das Erstellen des Images nicht viel. Allerdings hat die Dringlichkeit heute vielleicht etwas nachgelassen, aber zu Zeiten von Win95/98/ME kam das schön öfter einmal vor (manche scherzten, daß man 1x pro Jahr Windows neu installieren sollte, um die Registry wieder zu verschlanken). Früher hatte man auch noch sehr oft Computer, die mehrere Betriebssysteme alternativ booten konnten (Dualboot, Tripleboot, usw. - Rekord war mal ein Rechner mit 7 Installationen), da steckte in der Einrichtung oft noch viel mehr Arbeit. Im Falle von VM lassen sich heute die Images schnell erstellen und auch ebenso schnell wieder "zurückspielen". Ideal, wenn z.B. Software unter verschiedenen Betriebssystemen getestet werden soll. Und der andere typische Anwendungsfall ist der Tausch der Festplatte (wie beim TO). Gerade in Laptops paßt ja im Regelfall keine zweite Festplatte, daher ist der einfachste Weg eben: Booten von Medium, Image alte HDD -> externe HDD, Platte wechseln, Booten von Medium, Image externe HDD -> neue HDD/SSD, evtl. noch Partitionen anpassen, fertig. Funktioniert unabhängig vom Betriebssystem ohne große Kenntnisse zu erfordern.
(prx) A. K. schrieb: > Snapshot-Space auch ein separates Medium Damit könnte man z.B. verhindern, daß die Snapshots die Festplatte zumüllen. Oder man könnte dafür ein langsames und billigeres Medium verwenden. gerade bei VM, wo die VMs möglicherweise auf teuren RAID SSD Systemen liegen, könnten die Snapshots (und auch die Images) auf den langsameren, aber riesigen SATA Platten liegen.
kleiner Admin schrieb: > könnten die Snapshots (und auch die Images) auf den langsameren, aber > riesigen SATA Platten liegen. Nicht vergessen, dass die Snapshots dieses Verfahrens keine mit dem Zeitpunkt eingefrorenen Daten sind. Mit jeder ersten Änderung von Daten gegenüber dem Zustand zum Zeitpunkt des letzten Snapshots werden Daten aus dem Primärvolume in diesen Snapshotspace kopiert, plus Metadaten. Da diese Operation für die Konsistenz kritisch ist, kann die Performance eine Rolle spielen. Das ist ein Nachteil dieses Verfahrens gegenüber CoW, bei dem Snapshots rein statisch sind.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.