RO aus einem Backup ist ja OK.
Auch wenn du das bereits kanntest - es ist ja vllt. für andere Snapshot-Freunde interessant
RO aus einem Backup ist ja OK.
Auch wenn du das bereits kanntest - es ist ja vllt. für andere Snapshot-Freunde interessant
Zitat von tiermutterWie genau meinst Du das? Dazu müsstest Du ja die Daten vom Vault/Backup System via SMB o.ä. auf das Hauptsystem geschoben haben, oder
Ich wollte damit meine Begeisterung kund tun, dass ich in der FileStation im Snapshot-Vault einzelne Dateien des Snapshots sehen und kopieren kann. (Alles auf dem Backup-NAS.)
...habe nun Zwecks Test 2 Sicherungsmethoden gefahren:
a) RTRR über HBS3: 4,08TB in ca. 17h00 Stunden
b) Snapshop-Replica: 4,6TB in ca. 14h20 Stunden
Schnell geht anders - trotz GigE und passender Infrastrukur.
Die Snapshots im Vault auf dem Backup-NAS lassen sich sogar in der FileStation öffnen und man kann einzelne Dateien wiederherstellen.
Somit werde ich zukünftig die Snapshot-Replica-Methode verwenden.
Ob ich nun den totalen Ernstfall noch probe, weiß ich noch nicht - aber ich tendiere zum 'ja'
Da ich gerade ein Doc für unsere Sicherungsstrategy verfasse, kommt mir die Frage nach all dieser Sicherei auf, ob und wie oft man denn auch den Ernstfall proben sollte.
In meinem beruflichen Umfeld habe ich nicht nur einmal gehört, dass jahrelang mit einem großem Aufwand gesichert wurde - dann kam der Ernstfall! Gesicherte Daten beschädigt, Backup lies sich nicht einspielen, etc.....
Ich denke, es macht Sinn dies mindest. einmal im Jahr zu testen.
HOSTS:
Bei unseren Hosts mache ich das ca. einmal im Jahr in Form eines Acronis-TrueImage Komplett-Images des Systemlaufwerks. Dazu gibt es für jeden Host eine eigene bootbare USB-Festplatte. Dies hat sich absolut bewährt.
Dies dient vor allem der Installationssicherung. Wiederherstellung auf gleicher Hardware klappt super und schnell! Auf geänderter HArdware soll es auch klappen, tut es aber nur bedingt.
File-Server (QNAP-NAS):
Hier wäre zum Ernstfalltest folgendes nötig (Simulation eines neuen Gerätes):
- QNAP auf Werkeinstellungen setzen und HDD's initialisieren
- nach Neustart Wiederherstellung der Konfiguration durch xxxxx-bin (war vorgestern beim Versuch missglückt!)
- dann Rücksicherung der Nutzdaten vom Backup-NAS (RTRR oder Snapshot-Replica)
Wenn das alles problemlos klappt - Glückwunsch!!!! DAnn kann man ruhig schlafen....
Wie haltet ihr es?
Traut ihr euch ohne Not den Ernstfall zu proben?
Treibt ihr diesen Aufwand? wenn ja, wie oft?
Ich bin Neugierig auf eure Meinungen und insbesondere von denen, die dies beruflich machen.
tiermutter: herzlichen DAnk! Ich geb einen aus
ok, das habe ich dann wohl falsch verstanden.
Also ist ein Volume, egal ob Thick, Thin oder auch statisch, immer so groß wie ich es bei Erstellung manuell definiert habe.
(Mein Glaube war, dass das Thin bei erreichen eines Schwellwertes sich autom. um einen Betrag vergrößert solange der Pool noch Platz hat.)
zu meinem Verständnis ein Beispiel:
a) HDD=12TB (pysische Kapazität) -> Speicherpool=12TB (nutzbare Kapazität) -> 4TB Daten (genutzter Speicher) belegt autom. zugewiesene Kapaztät von 4,6TB in einem Thin mit 6GB (definierte Kapazität)
b) HDD=12TB -> Speicherpool=12TB -> 4TB Daten in einem Thick von 6GB (definierte=zugewiesene Kapazität)
größe der initialen Snapshot-Replicas:
bei a) 4,6TB
bei b) 6TB
Sinn der Überprovisionierung. Denkbares Szenario:
auf der HDD mit 12TB lege ich z.B. 3 Thin-Volumes mit je 12TB an.
Dabei wird die zugewiesene Käpazität in jedem Thin-Vol bei Bedarf autom. vergrößert.
Natürlich nur solange, wie der Speicherpool dies hergibt. Warnschwelle des Speicherpools wichtig! Warnschwelle der Thin-Vol. können deaktiviert werden.
Fazit: solange ich nur ein Volume in einem Pool betreibe ist es Wurscht ob ich Thin oder Thick wähle. Es sei denn ich möchte ein Snapshot-Replica erstellen.
Wenn ich also eine 12TB HDD habe und diesen nur zu Backupzwecken verwenden möchte, bieten sich zwei Konfigurationen an:
a) Backup auf Dateiebene, z.B. mit RTRR -> flaches Dateisystem ohne Speicherpool, statische Einzelplatte (ich weiß auf welcher pysischen HDD meine Daten liegen, evtl. Fremd-Auslesbar)
b) Backup auf Blockebene, z.B. mit Snapshots -> geht nur mit Speicherpool. Ein Snapshot-Vault-Volume wird beim Replizieren autom. erstellt. Daher erstelle ich nur ein kleines Thin-Vol fürs System (home, homes, Public) (oder kann ich den Pool ohne Volume erstellen?)
würde mich freuen, wenn ihr mich korrigiert, wo ich es falsch verstehe.
....it drivers me crazy
In der Nacht habe ich nun mein erstes RTRR-Backup auf meinem neuen Backup-NAS gefahren um Nutzdaten von meinem File-Server zu holen.
Situation:
File-Server: Thick-Volume 8,46TB mit 4,08TB Nutzdaten
Backup-NAS: Pool 12,72TB; Thin-Vol 2,46TG fast leer; Snapshot-Vault 8,46TB (nun gelöscht)
Screenshot nach Warnmeldung Speicher über 80% voll. 2,44TB sind nun im Thin-Volume.
Speicherplatz_DataVol1-Verwaltung_2.PNG
Ich habe die Funktion von Thin-Valomumes so verstanden, dass sie sich bei Bedarf autom. vergrößern.
Hier wäre nun noch Platz zum vergrößern von 1,7TB gewesen, warum ist das nicht passiert?
Habe ich ein Verständnisproblem?
du machst mir Angst! Ich wollte doch nur eine einfache, zuverlässige Sicherungslösung schaffen....
Aber vielen herzlichen Dank nochmal an alle hier, die sich so rege meiner Probleme annehmen! Ich versuche gleiches so gut ich kann.
alle Geräte sind im lokalen LAN.
Den Hosteintrag habe ich mithilfe der Lupe rechts neben dem Feld ausgewählt....
HA!! Nun habe ich die IP direkt, ohne Auswahllupe, eingetragen. Dann klappt's
Es geht mit IP und auch mit dem Namen. Dann wird der Text im Feld auch schwarz.
Vielen DAnk für die Inspiration!!!
...mein nächstes Problem:
Nachdem es schon mal funktioniert hat, kann ich nun auf meinem Backup-NAS keinen HBS3/Speicherplatz erstellen.
Beim drücken der Tasten "Detect Server", "Geschwindigkeitstest" oder "Erstellen" passsiert nix.
Ist bei euch auch der Host-Eintrag rot? Hat das was zu bedeuten?
So sieht die RTRR-Dienst-Konfiguration auf dem File-Server aus, wohin ich einen HBS3-Sync-Auftrag erstellen möchte
Eigentlich kann man da nicht viel falsch machen - oder habe ich einen Denkfehler?
Muß der RTRR-Server-Dienst auf beiden Seiten explizit gestartet sein?
Passwörter sind natürlich auf beiden Seiten gleich.
sorry, hat mir der Support so gegeben. Keine Ahnung. Aber ja, was was in Art muß es ausgeführt haben
Alles weise und richtig!
Aber auf so bekloppte Ideen kommt man, wenn ein Backup per USB-Disk 5Tage+ dauert und so eine dösige RTRR-Verbinfdung nicht will, wie sie soll....
Ich habe gerade mit dem QNAP-Support kontakt. Bevor ich also einen Neustart wage, höre ich mal, ob die mir helfen können. Vielen Dank!
Nachtrag:
der Support konnte helfen:
- per PuTTY eine SSH-Telnet-Verbing aufgebaut und folgenden Befehl abgesetzt:
/etc/init.d/init_lvm.sh
Dateisystem scheint wieder zu laufen. Jetzt muß ich prüfen, ob der Rest der Konfiguration i.O. ist.....
Firmware-Version 4.5.3.1652 Build 20210428
Platten tun was. LED's flackern. Wie lange würde denn wohl eine Reorganisation des RAID dauern? Gehen dabei Daten verloren?
Prozesse, welche nicht im Ruhemodus sind (Liste ändert sich aber ständig)
ich werd da nicht schlau daraus.
Du meinst, ob eine Reorganisation der RAID-Platten läuft? Woran erkenne ich das?
Ein Sync mit z.B. RTRR läuft nicht.
Beim Volume läuft die Uhr bei 'Freie Größe' seit gestern Abend.
Ich brauche dringend kompetente Hilfe!
AUf unserem neuen File-Server (TS-451D2-4G mit 4x4TB im RAID5) zeigt die Speicherpool-Verwaltung einen Fehler im Volume (Thick). NAS und Platten sind neu!
Was habe ich gemacht:
a) ich hatte die "Systemkonfiguration/Einstellungen zurücksetzen" ausgeführt, da ich die RTRR-Synchronisation nicht mehr ans laufen bekam
b) nach dem Neustart habe ich mich mit admin+MAC neu angemeldet
c) dann Zwecks Wiederherstellung meine am Tag zuvor gespeicherte Systemkonfiguration (xxxx.bin) vom PC hochgeladen und "Wiederherstellen" ausgewählt.
Seitdem ist mein Volume unbrauchbar. Ich traue mich nicht, das Ding nun auszuschalten oder irgendetwas zu unternehmen...
Da ich gerade dabei war ein Backup-NAS aufzusetzen, sind hier noch ungesicherte Daten
Ich bekam noch folgende eMail-Meldung:
QNAP2-Warnung
NAS Name: NAS4C0713
Severity: Error
Date/Time: 2021/12/20 21:18:54
App Name: Backup/Restore
Category: Backup & Restore Settings
Message: [Backup/Restore] Failed to restore system settings.
Welche Gründe kann es geben, das die Wiederherstellung nicht klappt?
Ideen, wie ich die Daten noch retten kann?
Systemkonfiguration_Einstellungen_zurücksetzen.PNG
Ich habe nun getestet:
- vorhandenen Speicherpool mit seinen Volumes gelöscht
- statisches Volume als Einzeldisk erstellt
(ich meine, dass beim ersten Setup ein Volume nicht ohne Speicherpool zu erstellen war.... aber ich kann mich irren)
Diese wurde nun in der RAID-Gruppe1 als EInzeldisk, nicht als RAID1 dargestellt.
(RAID1 wäre doch auch eine Spiegelung und würde 2 HDD's erfordern. Oder?)
Statisches Volume als EInzellaufwerk ohne Speicherpool.PNG
- jetzt habe ich ein paar Daten darauf geladen, Platte ausgebaut und versucht mit dem LinuxReader die Daten mit Windows zu lesen.
Ich hab's nicht hinbekommen. Vielleicht versteh ich das Linux-Konzept auch nicht.....
LinuxReader_stat_Volume_Einzeldisk_.PNG
Die gelben Partitionen sind von der QNAP-Disk. Habe versucht einzelne Partionen zu mounten. Aber mehr als Linux-System-Dateien und -Verzeichnisse finde ich nicht.....
....und HDS3 und RTRR-Sync bekomme ich seit dem nicht mehr ans laufen. Aber das ist eine neuer Thread
Vielen Dank. EIn hilfreicher ARtikel!
VOn ein paar Windows-Tools ist in dem Heise-ARtikel von FRS3263 zu lesen.
Das Einrichten einer Einzeldisk mit statischem Volume scheint mir aber nur innerhalb eines Speicherpools möglich zu sein. Oder gibt es noch einen anderen Weg?
Oder stört die Verwaltungsebene 'Speicherpool' das externe auslesen des ext4-Dateisystems nicht? Mir sind die Zusammenhänge zwischen Speicherpool und DAteisystem nicht klar.
Hallo,
ist es eigentlich mit QTS4.5.4 (TS-453D2) irgendwie noch möglich die Volumes einfach wie eine große externe Festplatte einzurichten. Ohne Speicherpool, ohne Snapshots.
Und zwar mit einem Dateisystem auf den Platten, so daß diese auch mit Fremdsystemen, wie einem Windows-PC, noch lesbar wären (FAT, FAT32,NTFS,exFAT,.....)?
Irgendwie missfällt mir der Gedanke für mein Backup-NAS, Daten dort so zu speichern, dass ich ohne QNAP nie mehr an meine Daten käme.
Stinknormale Dateisysteme aus DOS-Zeiten kann Windows heute immer noch lesen..... Irgendwelche Backup-Files aus irgendwelchen Backup-Lösungen hingegen nicht!
(vermutlich werde ich jetzt ausgelacht...)
ok, Danke erstmal! - erledigt -
ok, steckt eine gewisse Logik dahinter...
Habe gerade mal getestet, ob ich aus dem Snapshot-Vault (auf dem Backup-NAS) die Dateien extrahieren kann -> Geht!