Beiträge von aski

Hi,

ich nutze den Backup-Mechanismus der Virtualization Station, um täglich nachts um 3:00 ein Backup anzulegen.

Neulich habe ich meine virtuelle Linux-Maschine geklont, um größere Upgrades darin zu machen.

Danach habe ich die geklonte virtuelle Maschine weiter benutzt und die alte zum Cold Standby erklärt.

Dann habe ich den Backupjob in der alten virtuellen Maschine gelöscht und einen neuen Backupjob für die neue virtuelle Maschine in der Virtualization Station angelegt.

Seitdem funktioniert der Scheduler nicht mehr.

Wenn ich händisch ein Backup anlege, läuft das problemlos durch.

Das automatische Backup nachts um drei wird aber nicht mal mehr angestoßen.

Weiß jemand Hilfe?

Zusätzlich bekomme ich bei jedem Reboot meines TS-451+ nun folgenden Logeintrag von Virtualization Station:

Warning	2022-02-20	13:56:28	alxadm	<x.x.x.x> File Station	File Transfer	[File Station] Failed to copy "/homes/VMs/homie_00/.a637625e-8038-47db-b799-8f1a51b25f59.meta/snapshot/1643575164.state". Failed to access the file.
Warning	2022-02-20	13:56:28	alxadm	<x.x.x.x>  File Station	File Transfer	[File Station] Failed to copy "/homes/VMs/homie_00/.a637625e-8038-47db-b799-8f1a51b25f59.meta/snapshot/1644341612.state". Failed to access the file.
Warning	2022-02-20	13:56:27	alxadm	<x.x.x.x> File Station	File Transfer	[File Station] Failed to copy "/homes/VMs/homie_00/.a637625e-8038-47db-b799-8f1a51b25f59.meta/snapshot/1644372063.state". Failed to access the file.
Warning	2022-02-20	13:55:05	alxadm	<x.x.x.x> File Station	File Transfer	[File Station] Failed to copy "/homes/VMs/homie/.969da3b6-0b62-4a03-b873-0420b6f64132.meta/snapshot/1539780342.state". Failed to access the file.
Warning	2022-02-20	13:55:04	alxadm	<x.x.x.x> File Station	File Transfer	[File Station] Failed to copy "/homes/VMs/homie/.969da3b6-0b62-4a03-b873-0420b6f64132.meta/snapshot/1545309035.state". Failed to access the file.
Warning	2022-02-20	13:55:04	alxadm <x.x.x.x>  File Station	File Transfer	[File Station] Failed to copy "/homes/VMs/homie/.969da3b6-0b62-4a03-b873-0420b6f64132.meta/snapshot/1536667201.state". Failed to access the file.

Was will mir der Autor damit sagen? Und könnte es sein, dass das mit meinem Problem zusammen hängt?

Darüber hinaus scheint alles einwandfrei zu laufen.

Danke und Gruß

Alex

Gute Frage. Aus den Logdateien werde ich auch nicht schlauer. Da scheinen mir Logs von den letzten Tagen zu fehlen.

Aber danke für den Hinweis mit der nackten Win10 VM.

Also eher ein generelles Performance Problem der Kisten?

Das isses ja. Beide fast Leerlauf.

Das 451+ mit 50%, das 453 mit 20% CPU Last.

Auf dem 453 läuft noch eine Datensicherung Richtung extern. Die bläst mit 4 MB/s.

Aber das 451+ im internen Netzt hustet nur sporadisch Daten rüber, wie mir scheint. Das geht nicht über 20KB/s, gemäß Dashboard.

Dabei steckt da sogar eine SSD drin.

Hi zusammen,

ich nutze ein TS-451+ auf dem ich in erster Linie einen VM Server produktiv fahre und als Backupsystem ein TS-453.

Beide mit Raid-5 und beide mit zwei IP Adressen an einem Netgear Switch (da ich Port Trunking noch nie stabil zum Laufen gebracht habe).

Nun habe ich das Gefühl, dass Datentransfer zwischen den beiden Systemen eine gefühlte Ewigkeit braucht.

Gerade eben den Export meiner VM gestartet. Das brauchte schon mal 20 Minuten, bis es überhaupt losging mit der Übertragung. Dann dauert es Stunden, bis die 200 GB von 451+ nach 453 geschaufelt sind. Und dort wiederum Stunden, bis die virtuelle Maschine dann importiert ist.

Auch das Klonen einen 200GB VM auf dem 451+ dauert Stunden. Das kommt mir etwas suspekt vor.

Was sind denn da Erfahrungswerte?

Danke.

Wenn ich vier Einschübe habe und mit drei HDDs ein RAID5 mache, bleibt 1 Einschub für SSD.

RAID1 mit sich selbst wird dann eher nix.

Ergo nutzt auch die SDD im Schrank daneben nix, wenn die eingebaute die Grätsche macht.

So hab ich das jetzt zumindest verstanden.

Ich muss eh bald ne größere Migration machen. Zum Glück hab ich ein stetiges Backup der kritischsten Daten auf das 4xHDD RAID5, das daneben steht.

Insofern bin ich da wenigstens schon mal safe.

Sollte das das System nicht selber machen im Fall von Snapshots? Und bevor es überläuft alte löschen?

Wie verhindert man das Überlaufen von Snapshots?

Verstehe. Also ein QTier mit 3x RAID5 und 1x SSD führt im Zweifel in die Verdammnis.

Aber nur wenn die SSD ausfällt, richtig?

Wenn eine der 3 HDDs wegbricht, kann ich die tauschen, richtig?

Danke. Hm, klingt logisch.

Aber wenn das tatsächlich so rum ist, warum hat's mir dann vorhin das Volume gesperrt, als ich ein 1TB Daten von der externen Platte reingebuttert habe ... und dann zu Tieren angefangen?

Mysteriös ...

Hallo zusammen,

ich hoffe, ich bin hier halbwegs richtig mit meinen Fragen.

Leider finde ich zu QTier keine Dokumentation, die mir bei ein paar Verständnisfragen hilft, also versuche ich es mal hier:

Ich habe ein Thick Volume definiert, das aus einer SSD und 3 HDD (alle 4 Platten je 4TB) besteht.

Die 3 HDD bilden zusammen eine RAID5-Gruppe.

QTier sortiert die Daten hin und her.

Jetzt kann ich ja normalerweise in einer RAID5-Gruppe Hotswap machen, wenn eine Platte über den Jordan geht.

Ist das bei einem ge-QTierten Volume auch möglich?

Was passiert im Fall, dass die SDD über den Jordan geht? Stirbt mir dann das ganze System weg?

Würde das gerne mal verstehen, zwecks richtigem Backup Konzept.

Danke,

Alex

Ist das wirklich so?

Man kann doch pro Shared Folder einstellen, ob Auto Tiering für den Folder aktiv ist oder nicht?

Ich bin da gerade auf die Nase gefallen, weil ich es für einen Folder deaktiviert hatte und von einer externen Festplatte 1.4 TB reinkopieren wollte.

Aufgrund des ausgeschalteten Auto Tierings wollte das System scheinbar alles auf die SSD packen, bis QTS gesagt hat: Jetzt ist Feierabend. Ich schalte auf Read-Only und muss jetzt erstmal Tieren. Natürlich alles andere. Das hat dann auch nicht gereicht. Und so blieb mein Volume trotz vorhandenem Speicherplatz auf Read-Only. Bis ich den ganze Quark wieder gelöscht hatte.

Insofern ist meine Mutmaßung: Auto-Tiering für einen Shared Folder ausschalten. Dann bleiben diese Daten auf der SSD.

Kann das jemand bestätigen oder dementieren?