Tägliche erstelle ich von wichtigen Daten eine versionierte Kopie, über eine VM, auf ein zweites NAS.Hierzu nutze ich ein Tool namens SpoonBACKUP von einem Kollegen.
Mach woanders Werbung für eine nicht dokumentierte Windowssoftware.
Warum ist es nur ein Backup wenn man auf Tapes sichert?
Erstmal: Du legst 10.000km in 3h zurück? Wow, nicht schlecht, das würde ich auch gern könne (~ Mach 3). Zu deinem Problem:
Hallo Leute,
ich nutze die Virtualization Station recht intensiv. Deswegen lasse ich jeden Tag nachts von meinen VMs automatisch ein Backup auf die lokale NAS machen (sollte jemand ne VM hacken kann ich jeden Tag eines zurückspringen). Gleichzeitig hole ich anschließend von einem Backup-PC diese Dateien ab und speichere sie seperat nochmal (Hardware Defekt). Soweit so gut. In jedem Snapshot-Ordner (die aus einer Zahlenkombination bestehen) befindet sich jeweils noch ein versteckter Ordner darin (da Linux beginnend mit einem "."), dessen Namensgebung so ähnlich aussieht "ZAHL-ZAHL-ZAHL.meta"). Weiß jemand für was dieser Ordner gut ist? Grund: Ich habe einen speziellen Nutzer für Backups angelegt, der natürlich nur schreibgeschützten Zugriff auf die Daten erhält. Und dieser Nutzer hat auf die *.state Datei (irgendein Binary Blob?!) keinen Zugriff. Alternative Lösungsmöglichkeit: Wie zeige ich in der Filestation 5 versteckte Ordner an?
Vielen Dank für eure Hilfe!
Aha, dann hab ich das wohl übersehen...
Muss ich gleich mal ausprobieren ob das funktioniert wenn ich neue VM erstelle. Danke!
Nach dem Klonen und neu benutzen funktioniert das live backupen tatsächlich wieder! Danke
Ich habe mein NAS gerade auf 4.3.3 geupdatet, inkl. aller Apps die ein Update brauchten (weil sonst nicht mehr unter 4.3.3 ausführbar). In der alten Version habe ich mit Virtualization Station immer Live-Backups meiner VMs gemacht (in der Nacht), in einen anderen Ordner gespeichert und von dort (wenn das Backup fertig war) weggesichert. So hatte ich quasi immer einen aktuellen Stand aller meiner VMs inkl. eines Backups derer sollte sich die NAS doch mal verabschieden.
In der neuen Version gibt es keine Live-Backups mehr und mir ist jetzt auch kein Weg eingefallen wie ich diese Einschränkung umgehen könnte.
Weiß jemand von euch:
- Warum Live-Backups nicht mehr möglich sind (also die Gründe warum QNAP dieses Feature entfernt hat)?
- Ob man das irgendwie umgehen kann um trotzdem Live-Backups durchführen zu können?
Welche Firmware Version nutzt du denn?
Die Virtualization Station setzt auf QEMU auf, was wiederrum einen Linux Unterbau mit KVM erfordert (naja nicht unbedingt, es ist aber stark davon auszugehen das das funktioniert). In welcher Version von Qemu weiß ich nicht, wenn du aber nach "QEMU Live Backup" oder dergleichen suchst wirst du recht schnell fündig. Im Grunde ist QEMU sehr sehr stabil und Backups funktionieren. Auch das zurückspielen funktioniert.
Allerdings habe ich mit 4.3.3 nicht mehr die Möglichkeit Live-Backups durchzuführen ...
habe mir eine TS453a gekauft und auf 16GB Ram erweitert. Meine Platten sind 2x2TB+1x4TB+1 SSD 60GB (Cache).
Das ist schön. Nur verlierst du kein Wort darüber, wieviel Resourcen du den VMs zuweist. (CPU/RAM).
Habe VM und 2x Win7
mit den virtIO Treibern installiert. Jedoch sind die VM sehr träge - kein Vergleich zu einem Original bzw. einer VM unter MacOS.
Windows habe ich auch probiert. Auch bei einer X45A. Kannste vergessen. Ein Windows Server könnte u.U. noch gehen, ein Windows 7 (auch mit dem ganzen deaktivierten Desktopkram) läuft einfach nicht. Dafür ist der Prozessor einfach zu lahm. Eine Server - Linux Installation (keine GUI) läuft flüssig, mit GUI hab ich noch nix ausprobiert, eine sehr leichtgewichtige wie LX(DE|QT) würde wahrscheinlich einigermaßen rund laufen.
Wie sich NFS über physikalische Grenzen hinwegsetzt, erschließt sich mir ebenso wenig.
Hab ich nicht gesagt 
Die theoretische Obergrenze im Gigabit-LAN liegt bei 125 MB/s. Ich kopiere (per SMB) mit durchschnittlich 110-118 MB/s.
Mit smb komme ich, bei "guten" Daten, auf ein ähnlich hohes Maß. Vor allem aber bei vielen kleinen Dateien hat nfs die Nase meilenweit voraus
Ich bin
Bin gespannt wie ihr das macht oder seid ihr ein Backupmuffel
Ich bin jetzt endlich mit meiner Backup Strategie zufrieden (zumindest zu 95%, die restlichen 5% erkläre ich am Ende ;).
Daten auf der NAS: aktuell "nur" 1 TB, Daten von mir/Lebensgefährtin. Daten sind alles mögliche, dass geht von Bilder/Videos über Dokumente bis zu Backups von meinem und ihren PC. Also Dinge, die gebackuped werden wollen 
Zusätzlich laufen auf meiner NAS noch 2 VMs (insgesamt 115 GB) die ich auch gerne backupe.
Ich habe seit langer Zeit noch einen "Stromspar-PC" (also PC mit billig Mainboard, ASROCK J1900 mit aufgelöteter CPU), dadrin werkelt ein RAID1. Diesen nutze ich als Backupserver.
Von aktiven Backup (also die NAS, die ich eigentlich Backupen will schreibt die Daten auf das entfernte Medium, egal ob per RTRR oder RSYNC) halte ich nicht so viel. Sollte, wider Erwarten, doch irgendwann mal jemand auf meine NAS kommen, dann kann er quasi in Echtzeit die Daten auf dem Backup auch löschen. Genau das soll verhindert werden. Die Lösungen sind IMHO nur für Hardwarefaults gut, für Softwarefaults (oder Angreifer) aber überhaupt nicht geeignet.
Deswegen nutze ich die etwas umständlichere Lösung, die aber auch nicht zu 100% Ausführung auf dem NAS auskommt.
Backupserver mounted alle zu sichernden Verzeichnisse per smb/nfs (wenn QTS 4.3 mit nfsv4 aus dem Beta raus ist dann nur noch mit nfs, weil schneller). Dafür eigenen Nutzer erstellt, der nur lesenden Zugriff auf die Verzeichnisse hat. Dann backupe ich alle Verzeichnisse mit borg backup (arbeitet mit chunks, deswegen auch sehr gut für VMs geeignet) auf den Backup PC. Borg verschlüsselt und komprimiert die Daten während der Sicherung. Durch das Verwenden der Chunks wird der Spass aber von Haus aus sehr viel kleiner.
Die VMs backupe ich bisschen anders: Ich lasse die NAS täglich in der Nacht einen Livesnapshot der VMs machen und nach 3 Tage löschen. Da Borg auf Chunk Ebene mit Komprimierung arbeitet werden so aus 345GB VMs (3x100GB + 3x15GB) im Prinzip dauerhaft nur etwas mehr als ca. 80GB. Das ist ziemlich geil, ich kann quasi beliebig durch die Vergangenheit rauschen, alle Stände zurückspeichern wenn ich will und verbrauch trotzdem nicht viel Speicherplatz).
Für die restlichen 5% (mein Haus inkl. NAS und Backupserver fackeln ab 
) würde ich eigentlich gern das verschlüsselte Borg-Backup zu irgendeinem Cloudstorage Anbieter synchronisieren (Backblaze, crashplan etc.), nur leider ist meine Internetleitung viel viiiehl zu langsam 
. Ich müsste für das initialie Backup knapp 1 Monat synchronsieren, und das geht sich dann doch nicht ganz aus.
Ich werd mir demnächst deswegen noch ein kleines Skript schreiben, das für die wichtigsten Daten/Verzeichnisse (werde ich irgendwie markieren z.B. durch Dummydateien) in einem extra Borg Repo speichert und synchronisiert. Da das maximal 1-2GB sind kann ich das dann mit rsync zu Backblaze oder sonstwen hochladen.
Wichtige Dateien sind hauptsächlich unverzichtbare Dokumente. Um Fotos/Videos etc. ist es zwar schade, aber die sind nicht Überlebensnotwendig.
spielt doch eine untergeordnete Rolle Ist ja nur die GUI für FSArchiver und richtige Linux Geeks arbeiten eh nur auf der Konsole 
Der PC greift nicht direkt auf das Dateisystem des NAS zu, sondern über das Netzwerk (SMB).
Daher wird hierbei auch ISCSI höchstens einen marginalen Effekt erzielen.
Ich habe ISCSI bis jetzt nur innerhalb von VM Clusters benutzt und habe keine Datenraten gemessen. Aber es sollte auf alle Fälle einen Unterschied machen. SMB ist IMHO ein ziemlich schlechtes Protokoll (bzw. ziemlich lahm), vor allem bei sehr kleinen und sehr großen Dateien. Alleine NFS ist SMB teilweise um Faktor 100 voraus (selbst bei mir im Netzwerk gemessen, irgendwo habe ich sogar noch den Exceloutput).
Naja zusammenfassend: Programme übers Netzwerk zu starten dauert halt, da braucht man sich nicht wundern.
Ja ne. Ich mein, wenn jemand will, dass niemand Zugriff drauf haben darf, dann darf ich da keine einfache serielle Schnittstelle draus machen. Genau dann muss ich USB o.ä. verwenden und irgendein Protokoll mit Verschlüsselung einbauen. Das was QNAP da macht ist einfach nur Security through obscurity und sonst nix. Ich konnte ja schon einen kurzen Ausschnitt mitloggen, vielleicht schaff ichs mir am Wochenende einen Adapter zu basteln. Wenn man dann relativ einfach auf die NAS kommt, dann ist das, wenn man deiner Begründung folgt, ein Problem.
Ich würde gern meine Systeme (vorrangig Linux, 1x Arch Linux, 1xUbuntu) abends per Klick komplett auf mein NAS sichern. Sprich ich würde im Fall eines Fehlerhaften Updates oder ähnlichem gern einfach das komplette System wiederherstellen können, mit allen Daten und installierten Anwendungen. Wichtig sind mir dabei folgende Punkte:
Ist doch meistens gar nicht notwendig. In der Zeit wo du das Update wieder einspielst hast du auch die fehlerhaften Updates zurückgespielt und wieder auf den alten Stand gebraucht. Kernel wird eh nicht automatisch gelöscht, starten kann das System also immer (zumindest nach GRUB).
das Backup soll aus dem aktuellen System gestartet werden können (sprich Clonezilla ist keine Alternative, da dort immer die Partitionen ausgehangen sein müssen)
Können so gut wie alle Systeme (rsync, borg-backup), die nicht ein ganzes Festplattenabbild machen.
es wäre wünschenswert wenn die Sicherung inkrementell erfolgt, da ich sonst befürchte, dass das Backup die ganze Nacht dauert, wenn immer ~500GB durchs Netz geschoben werden müssen
Gilt ebenso wie der zweite Punkt, außer du bestehst wirklich auf ein Festplattenimage.
Nun ich kann die QT4FSArchiver empfehlen, hab es selbst in gebrauch.
Kannte ich noch nicht, liest sich aber gut. Scheint auch auf das Problem des TO zu passen, allerdings
Die Sicherung der eingehängten Root- oder Home-Partition ist, nach einem Warnhinweis, möglich. Dabei ist zu beachten, dass qt4-fsarchiver fortlaufend sichert. So ist es kein Problem, im Internet zu surfen oder mit dem Mailprogramm zu arbeiten. Während der Sicherung ein Programm zu installieren oder das System zu aktualisieren macht keinen Sinn, da solche Änderungen überhaupt nicht oder nur teilweise gesichert werden. Das System kann dadurch beschädigt werden.
Der oben erwähnte Partition Boot Record (PBR) sind die ersten 512 Bytes einer jeden Partition. In den PBR kann auch der Bootmanager eingetragen werden. GRUB unterstützt den PBR nicht, so dass bei Nutzung von GRUB als Bootmanager der PBR nicht gesichert oder wiederhergestellt werden muss. Diese Option ist nur bei Verwendung von anderen Bootmanagern eventuell sinnvoll.
Also doch nicht so einfach, oder sehe ich das falsch. Die meisten Linux Systeme sollten Grub benutzen, also muss man doch wieder mit der Hand ran.
Du hast auch nicht gesagt, dass es nix kosten darf
Es gibt diverse kostenpflichtige Tools die sowas können z.B. Acronis. Kostet halt einmalig 500-700€, die funktionieren aber i.d.R. gut.
Was auch noch funktionieren würde: Nacktes System installieren, via LXC eine VM aufbauen. Diese kannst du dann auch im Livebetrieb sicher und zwar komplett. Damit wärst du auch nicht mehr auf deine HW beschränkt, sondern könntest z.B. auch schnell auf nen anderen PC umziehen, falls deiner verreckt. Nur so als Gedankenspiel...
Ich denke nicht das da irgendein Problem mit der NAS besteht. Ich selbst nutze kein Windows, sondern nur Linux. Ich versuche mal eine mir logische Erklärung abzugeben:
1. Windows unterstützt das zugrundeliegende Dateisystem deiner NAS nicht. Das bedeutet erstmal, dass du keine Dateien von einem cifs share ausführen kannst. Windows braucht also eine Lösung für dieses Problem. Die Lösung wird vermutlich bei jedem Programmstart durchgeführt und kann halt kurz dauern.
2. Windows muss das ganze Programm zur Startzeit in den RAM laden bzw. irgendwo auf deinen Rechner in ein temporäres Verzeichnis kopieren um es auszuführen. Das dauert halt ein bisschen. Es ist halt doch was anderes wenn du ein Programm startest wie wenn du nur Daten kopierst.
Fazit: Bei 20s vs. 5s würd ich mir keine Gedanken machen (vor allem weil vergangene Zeit immer subjektiv ist, lokal hast du evtl. eine SSD im NAS aber nicht).
Naja ein VMWare ist ja auch eine Komplettvirtualisierung. Die Linux Station nutzt IMHO LXC und baut darauf auf.
LXC lässt übrigens auch snapshots eines live systems zu, die Integrität wird auch gesichert. Über ssh drauf und dann via lxc-snaphot loslegen, siehe man pages
http://man7.org/linux/man-pages/man1/lxc-snapshot.1.html
python
usbhid-ups
hd_util
python -> Hintergrundprozess für den python Interpreter. Wird wohl für diverse Hintergrunddienste von QNAP verwendet, warum auch nicht Ein Dienst, der Python auf alle Fälle nutzt ist QSirch (habe ich auf die schnelle ausfindig machen können). Das der Dienst dann rel. viel Resourcen Verbraucht kann damit zusammenhängen, dass QSirch außerdem noch Java braucht. Vielleicht startet irgendein python Prozess die Java VMs und deswegen sieht python schuldig aus.
usbhid-ups -> Wie der Name schon sagt Ich trenne den Namen mal in 3 Teile, dann kommst du selber drauf USB, klar was das ist. HID -> eigentlich ein Human Interface Device (Tastatur), es gibt aber auch Geräte die sich als solche anmelden. Du besitzt wohl eines. UPS -> USV nur auf Englisch. -> Hast du eine USV angesteckt?
hd_util -> läuft bei mir nicht. Ich könnte mir vorstellen, dass das ein Hintergrundprozess zum Verwalten der HDDs ist. Evlt. zur Abfrage von smart werden oder zum parsen für die Weboberfläche
irq/304-80860F1
Schwierig, ist eine sehr komische Prozessnummer. irq beschreibt i.d.R. Interrupts, also externe Interaktionen, die den Kernel zum "sofortigen" Handeln auffordern. Dazu gehören z.B. Mausklicks oder auch Festplattenaktivitäten.
ich habe ein problem und zwar: ich habe eine software mit datenbank und co auf eine nas (qnap TS-231 p)verlegt, nun startete die warenwirtschaft extrem langsam.
Lokal startet sie normal schnell in ca. 5 sekunden, von der NAS braucht sie ne gute minute oder länger.
Mich würde dein genauer "Ablauf" interessieren?
Du hast eine Ausführbare Datei auf dem NAS gespeichert?
Eingebunden hast du die NAS über die Windows Freigabe, also über cifs?
Du startest die exe, diese wird also bei dir am lokalen Windows PC ausgeführt?
Wo ist die Datenbank? Bzw. wohin verbindet sich die Anwendung bzw. mit welcher Datenbank und wo liegt der Datenbankserver?
Hallo Leute
letzte Woche war es soweit: Nach über einem halben Jahr Dauerbetrieb musste ich meine NAS hart ausschalten. Warum das? Ich hatte mit der "Hybrid Backup Sync" rumgespielt und wollte einen Sync zu einem entfernten FTP Server machen. Eigentlich nix großes (40MB, nur zum testen), allerdings ist mein Upload wirklich langsam. Den Job also gestartet und nach ca. 1 min hat sich die NAS komplett aufgehangen. Es ging überhaupt nix mehr, nur nfs mount... Kein ssh zugriff, keine Weboberfläche, einfach nichts mehr. Ok hilft ja nix, also hart ausgeschaltet. Da ich das überhaupt ganz und gar nicht leiden kann, habe mich auf die Suche nach Zugriffsmöglichkeiten gemacht, die auch noch gehen wenn sich die meisten Dienste verabschieden. Damit sind alle Dienste wie ssh, http, VMs etc. gemeint.
Relativ schnell fündig geworden, meine NAS hat einen "Wartungsport". Meine Vermutung: Irgendeine Standard-serielle Konsole, die als tty oder ähnlich agiert. Dann habe ich mich also auf die Suche nach Informationen darüber gemacht und wurde rel. schnell bei einem Review/Teardown meiner NAS fündig https://www.techpowerup.com/reviews/QNAP/TS-453A/. Dort ist ganz klar ein RS232 Treiber drauf, also doch eine normale serielle Schnittstelle, jpi 
. Um nicht an meiner NAS rumprobieren zu müssen habe ich den QNAP Kontakt kontaktiert und höflich nachgefragt, ob Sie mir denn die Informationen liefern können (Assignement der Kopfhörerbuchse, logische Pegel, etc...). Antwort: Nein ist nur für die Entwickler in Taiwan . Toll, was ein Kack. So ne Miniinformation gibt man nicht raus... Um so eine Schnittstelle zu "reverse engineeren" braucht man nicht viel können, aber es gibt ein besseres Gefühl wenn man seinen Stecker reinjagt...
Also musste ich doch selbst ran. Mit Logic Analyzer und nem billigen USB-UART Wandler (leider nur 5V...) angesteckt und... Erstmal nix, also ein paar Zeichen runtergeschickt. Oha, dachte ich mir, da passiert ja nix. Also geschaut ob ich noch Zugriff auf meine NAS hab und... schon wieder abgeschmiert! 
Hä, warum denn das? An den Pegeln könnte es liegen, wenn ich zusätzlich RX und TX vertauscht hätte (wie es auch war, und das bei einer 50:50 Chance 
). OK, NAS reagiert nicht mehr. Also kurz gewartet, UART Wandler abgesteckt, nur noch Logic Analyzer drauf gelassen und einfach mal gewartet. Nach ca. 5min hat das Ding gepiepst und neu gestartet. Na immerhin diesmal... 
.
Schnell nen Trigger am LA konfiguriert und geschaut ob was passiert. Tatsächlich, jetzt konnte ich einen kleinen Teil der Kommunikation mitsniffen. Leider muss meine NAS mein raid erst wieder resynchronisieren, irgendwas ist wohl doch schiefgelaufen bei dem ausschalten , sonst hätt ich jetzt gleich noch weiterprobiert.
Soweit zu meinem Teil, hier die Infos die auch rausbekommen habe:
Belegung Klinkenstecker:
Spitze = TX vom QNAP
Mittelteil = RX Richtung QNAP
Hinterer Teil = GND
logische Pegel entsprechen dem RS232 "Standard.
Baudrate = 115200 Baud
Damit kamen beim Starten des NAS log Nachrichten über das Interface raus. Ich hab jetzt nicht mehr ausprobiert ob man über das Interface auch interagieren kann, gehe aber stark davon aus, weil ich denke der Port ist einfach /dev/tty1. Würde ich auch so machen..., evtl. werden auch keine credentials am Port abgefragt.
Nun meine Frage:
Hat schonmal jemand von euch mit dem Wartungsport rumgespielt/Erfahrungen gemacht?
Hat jemand von euch weitergehende Informationen zum Wartungsport?
Warum weigert sich der QNAP Support solche trivialen Informationen rauszugeben? Da bin ich bis jetzt schon etwas enttäuscht
Linux Station hab ich zwar noch nicht benutzt, aber was ich darüber gelesen hab soll das ja ein Desktop Ersatz sein.
LXC Container sind ein Mittelding zwischen VMs und Anwendungsvirtualisierung wie Docker.
Innerhalb des Containers kann ich normal arbeiten, es ist trotzdem unglaublich performant.
Außerdem kann ich mehrere Container parallel laufen lassen (wie halt bei VMs auch), ohne das diese sich gegenseitig in den Weg kommen.
Das optimale für sowas wären dann noch unpriviligierte LXC Container, was bedeutet, dass der Container mit normalen Userrechten (z.b. foo) läuft und nicht als admin.
Ist ganz interessant. Bekomme den gleichen Fehler bei einem manuell (also per Hand über die Kommandozeile) importierten LXC Container.
Ich vermute das hat mit den Rechten des darüberliegenden LXCs zu tun.
Erstellt hast du den Container als "admin" über die Benutzeroberfläche?
Edit: auch bei einer über die Standardinstallation geholtest Debian geht das bei mir nicht.
Außerdem installiert er Packete nur so halbscharig nach, da gibts auch Rechteverletzungen (diverse).
Ich werde jetzt die Containerstation mal nochmal neu installieren, inklusive alle Ordner löschen. Mal schauen ob sich dann was ändert.
