System Go Back ala Windows Recovery oder ähnl.?

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von schorsch_76 » 27.04.2017 09:40:27

Lord_Carlos hat geschrieben:
Deny hat geschrieben:ext4 geht überall. Bei anderen ist es Glückssache.
Was meinst du damit?
Bei btrfs fällt mir immer wieder das hier ein: (Seite 3). Ja, ich habe auch schon btrfs eingesetzt. Snapshots sind schön, aber Backups sind besser ;)

[1] http://events.linuxfoundation.org/sites ... 2016_0.pdf

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von scientific » 27.04.2017 10:54:31

schorsch_76 hat geschrieben:
Lord_Carlos hat geschrieben:
Deny hat geschrieben:ext4 geht überall. Bei anderen ist es Glückssache.
Was meinst du damit?
Bei btrfs fällt mir immer wieder das hier ein: (Seite 3). Ja, ich habe auch schon btrfs eingesetzt. Snapshots sind schön, aber Backups sind besser ;)

[1] http://events.linuxfoundation.org/sites ... 2016_0.pdf
Sehr nett... Aber das PDF gibts an der Stelle nicht mehr...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

owl102

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von owl102 » 27.04.2017 10:55:58

Deny hat geschrieben:Geht das Update jedenfalls schief, macht es eine automatische zurückstellen zum letzten zustand. Es dauert zwar Ewigkeiten, aber das System läuft dann wieder.
Funktioniert das denn unter Windows 10 (endlich)? Unter Windows 7 funktioniert das auf jeden Fall nicht, wir hatten diverse Male den Fall, daß wir genau das Problem hatten und das Zurücksetzen dann auch nicht klappte. Windows 7 hat sich stattdessen in eine Endlosschleife "Zurücksetzen" - "Neustart" - "Updates konfigurieren - schlägt fehl" - "Neustart" - "Zurücksetzen"... begeben.
Mal sehen was mir noch so einfällt, das doch auch nachzuahmen.
Den Mechanismus von Windows würde ich nicht nachahmen wollen. Viel sinnvoller und robuster sind Snapshots auf Dateisystemebene (und eine separate /home-Partition), so, wie openSUSE es seit Version 13.2 per default macht. [1] Und (Open)Solaris bzw. Illumos und BSD seit einer gefühlten Ewigkeit in Zusammenarbeit mit ZFS.

[1] https://www.bitblokes.de/2014/11/btrfs- ... vorhanden/
Zuletzt geändert von owl102 am 27.04.2017 12:06:52, insgesamt 5-mal geändert.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von Lord_Carlos » 27.04.2017 11:16:46

owl102 hat geschrieben: Viel sinnvoller und robuster sind Snapshots auf Dateisystemebene (und eine separate /home-Partition), so, wie openSUSE es seit Version 13.2 per default macht.
Ohne BTRFS oder Suse benutzt zu haben, kann es sein das die Subvolumes bentuzten fuer /home?
So viel ich weis kann man Snapshops von subvolumes machen.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

owl102

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von owl102 » 27.04.2017 12:03:32

Lord_Carlos hat geschrieben:Ohne BTRFS oder Suse benutzt zu haben, kann es sein das die Subvolumes bentuzten fuer /home?
AFAIK ist der default für /home XFS. (BTW: Ich habe Suse seit über 20 Jahren nicht mehr benutzt, genaues weiß ich also auch nicht.)

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von scientific » 27.04.2017 12:19:46

Suse arbeitet mit Snapper mit einer relativ complexen Struktur an Subvolumes auf EINER Partition.
Ich habe diese Struktur für meine Lösung auch übernommen.

Ein Subvolume für das System.
Ein Subvolume wo wiederum Subvolumes drinnen sind, jeweils mit Userdaten, Emails, Webserver, Datenbanken...
Diese Subvolumes werden dann über die fstab in das subvolume für das System gemountet.

Damit kann ich einen Systemsnapshot machen - und es so auf einen früheren Zustand zurücksetzen ohne dass Userdaten, Emails, Datenbankbestände... verlorengehen.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von TomL » 27.04.2017 15:43:10

schorsch_76 hat geschrieben:Snapshots sind schön, aber Backups sind besser
Ich bin der gleichen Meinung. Mir wäre der Aufwand mit Snapshots zu hoch. Bei Windows kann ich das noch verstehen, wenn man vielleicht frühere Aufsetzpunkte wieder herstellen will.... aber bei Debian sehe ich auf keinem einzigen unserer Rechner dafür eine Notwendigkeit. Kein einziger unserer Rechner hat lokale Daten gespeichert, kein einziger hat von unserem Standard abweichende Einstellungen. Wenn irgendeiner der Rechner stirbt, bügel ich einfach ohne lang drüber nachzudenken den passenden Net-Iso-Installer drüber, kopiere ein paar (unserer spezifischen) Standard-Settings rein und nach 2, spätestens 3 Stunden läuft der Rechner wieder so, dass der Anwender nicht mal bemerkt, dass ein neues Debian drauf ist. Ich setze auch lieber auf regelmäßige Backups und möglichst einem (unserem) Standard entsprechenden Rechner-Setups, damit ich eben keinen Wiederaufsetz-Punkt brauche, sondern ohne lange überlegen zu müssen kurzerhand einfach neu installieren kann.

Allerdings experimentiere ich auch nicht viel auf unseren Rechnern rum. Zum Testen vor bestimmten Installationen oder bei gravierenden Änderungen verwende ich -als echte Maschine- einen Pi als Test-System. Darüber hinaus teste ich -sofern machbar- Neuigkeiten in VMs's und neuerdings auch in systemd-nspawn. Mit system-nspawn installiere ich, wenn ichs brauche, in Minuten ein komplett neues Debian einfach eben im RAM nach tempfs. Auf die produktiven Rechner transportiere ich nur getestete und sicher funktionierende Lösungen. Als ich jetzt zuletzt unseren Mailserver aufgesetzt habe, wurde das bis zur vollständigen Fertigstellung und komplett fehlerfrei durchgespielten Tests nur auf dem Test-System gemacht. Der anschließende Transport und die Inbetriebnahme auf dem Server waren dann eine Sache von 15 Minuten. Einmal neu durchstarten und seit dem läuft das ohne Probleme und Auffälligkeiten.

j.m.2.c.

owl102

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von owl102 » 27.04.2017 16:25:27

TomL hat geschrieben:
schorsch_76 hat geschrieben:Snapshots sind schön, aber Backups sind besser
Ich bin der gleichen Meinung.
Ich nicht. Für mich haben Snapshots nur wenig mit Backups zu tun, für mich sind das zwei verschiedene Paar Schuhe.

Snapshots nehme ich für das System (bzw. mein Illumos-Server macht vor einem Update automatisch einen Snapshot), Backup für Daten.
Zuletzt geändert von owl102 am 27.04.2017 16:51:01, insgesamt 1-mal geändert.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von Lord_Carlos » 27.04.2017 16:48:11

TomL hat geschrieben: Mir wäre der Aufwand mit Snapshots zu hoch.
Ja, unter debian :)

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

owl102

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von owl102 » 27.04.2017 16:58:30

TomL hat geschrieben:Wenn irgendeiner der Rechner stirbt, bügel ich einfach ohne lang drüber nachzudenken den passenden Net-Iso-Installer drüber, kopiere ein paar (unserer spezifischen) Standard-Settings rein und nach 2, spätestens 3 Stunden läuft der Rechner wieder so, dass der Anwender nicht mal bemerkt, dass ein neues Debian drauf ist.
"nach 2, spätestens 3 Stunden" 8O Das sind 2 bis 3 Stunden, an denen x Mitarbeiter nicht an ihre Daten herankommen und zurecht die IT-Abteilung verfluchen. Bei einem Snapshot wäre das lediglich ein Neuboot mit passender Snapshotauswahl.

Außerdem schließe ich mich Lord_Carlos an, was den Aufwand von Snapshots angeht: Welcher Aufwand? Bei BSD oder Illumos oder openSUSE ist das kein Aufwand, im Gegenteil, es wäre Aufwand, es anders zu installieren.

TomL

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von TomL » 27.04.2017 17:15:57

owl102 hat geschrieben:Das sind 2 bis 3 Stunden, an denen x Mitarbeiter nicht an ihre Daten herankommen und zurecht die IT-Abteilung verfluchen.
Damit kann ich prima leben....*fg*... meine erste Reaktion wäre sowieso... "sorry.. sags mir nach dem Frühstück... und Frühstück ist zu Ende, wenn ich die Zeitung gelesen habe... und falls ich danach ein verkniffen Gesicht mache, musste noch mal ne viertelstunde warten... gibt halt Dinge, die wichtiger sind."

Also... ein paar Vorteile hat es schon Rentner zu sein... da gewöhnt man sich Ruhe an... Hektik war vorvorgestern.... :D ... bei mir gehts natürlich nicht um vertraglich einzuhaltende Verfügbarkeitsgarantien.... :lol:

owl102

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von owl102 » 27.04.2017 17:34:15

TomL hat geschrieben:gibt halt Dinge, die wichtiger sind.
Das ist aber kein Argument, sondern ein Todschlagargument. Gehen die die Argumente aus? :mrgreen: (So kenne ich dich gar nicht. :wink: )
Also... ein paar Vorteile hat es schon Rentner zu sein... da gewöhnt man sich Ruhe an...
Das mag ja sein, aber mit dem richtigen System sind Snapshots IMHO trotzdem eine gute Sache (und im professionellen Umfeld eine sehr gute Sache) und kein extra Aufwand, im Gegenteil :wink:
Hektik war vorvorgestern.... :D
Genau, denn heute gibt es Snapshots, so daß man eben im Bedarfsfall keinen Stress hat.

Und es wird IMHO mehr als Zeit, daß auch Debian dies ready-to-go in den Installer integriert.

TomL

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von TomL » 27.04.2017 18:17:20

owl102 hat geschrieben:Snapshots nehme ich für das System (bzw. mein Illumos-Server macht vor einem Update automatisch einen Snapshot), Backup für Daten.
Wenn ich häufiger mal manuell durchgeführt via Script sämtliche Einstellungsdateien auf dem Server sichere, betrachte ich das auch als Backup, auch wenn diese Daten nicht der klassischen Definition von User-Anwendungs-Daten entsprechen. Bezogen auf meinen Blickwinkel würde ein vollständiger Snapshot eben auch noch die Binary's umfassen. Aber genau das will ich hier nicht. Mit anderen Worten, die letzte vollständige laufende Systeminstallation vor dem Upgrade sichern... das wäre mir vor dem Hintergrund mehrerer Clients viel zu aufwendig, zumal diese via Auto-Upgrade eh ihren eigenen individuellen Zyklus haben. Was meinen Server angeht... nun ja... der hat bis auf bestimmte Ports (OpenVPN, NTP, Abfrage POP3) keine weitere Internet-Erlaubnis, schon mal gar nicht ausgehend, dem ist alles rigoros verboten. Und das monatliche Upgrade führe ich immer nach dem 4. durch, nach manueller Deaktivierung des rigorosen Paketfilters. Nach dem 4. deshalb, weil am 4. einmal "/" komplett automatisch gebackup't wird. Und wenn ich das mal einen Monat vergesse, so nach dem Motto "never touch a running system" ist das auch nicht weiter schlimm. Wie gesagt, dem Server ist im wesentlichen kein Zugriff ins Internet (ausgehend) erlaubt. Und bezgl. eingehend funktioniert NUR der OpenVPN-Port.

Ich versuche halt den Wartungs-Aufwand aller Systeme durch sehr restriktive Organisation so gering wie möglich zu halten.
owl102 hat geschrieben:Gehen dir die Argumente aus?
Ja sicher... weil es definitiv keine sinnvollen Argumente gibt, die wichtige oder notwendige oder mögliche Maßnahmen zur Aufrechterhaltung der Systemintegrität infrage stellen. Dagegen zu argumentieren wäre doch dumm.

Ich kritisiere das auch überhaupt nicht pauschal und allgemein. Ich betrachte das lediglich ein wenig oberflächlich und egoistisch bezogen nur auf mein Umfeld. Der Aufwands-Gedanke kam mir in den Sinn, als mir beim Lesen (weiter oben) von subvolume in subvolume mit je weiteren subvolumes in Partition regelecht schwindelig wurde. Da war meine erste Reaktion "Hier...?... sowas...?... auf gar keinen Fall". Aber das ist keine Pauschalkritik, sondern lediglich auf mein Netz bezogen, und möglicherweise auch ein wenig von Unkenntnis geprägt. Allerdings hängt diese Sichtweise (bzw. ist dadurch entstanden) an der gewohnten Stabilität unserer Debian-Installationen, wie ich sie jetzt im dritten Jahr erlebe. Und das ist eindeutig....Debian hat sich bei unserer Art des 'Handlings nach gewissen Regeln' als beispiellos stabil erwiesen.

Der absolut seltene 2-3 Stunden-Aufwand für eine Neuinstallation ist in Summe geringer, als ich an Aufwand für regelmäßige Snapshots der Clients betreiben müsste, die ich nach meiner Erfahrung sowieso nicht nutzen müsste, weil Debian sowieso einfach weiter läuft. Allerdings bin ich hinsichtlich der User-Daten-Sicherung vermutlich eher paranoid.... *lol*.... gearbeitet wird auf SSD, die dann täglich automatisch nach HD_1 gesynct wird, an 9 weiteren Terminen im Monat gehts automatisch von HD_1 nach HD_2... und willkürlich von (adhoc aktualisierter) HD_1/HD_2 auf 3 rollierende Schließfach-HDs. Die HD_* sind (bis auf eine Multimedia-Freigabe) von den Client-PCs nicht erreichbar.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von scientific » 28.04.2017 02:46:55

Snapshots und Backups sind auch für mich zwei verschiedene Paar Schuhe, wenngleich auch ähnliche.

Wenn dir @TomL beim Gedanken an Subvolumes und Subvolumes in Subvolumes schwindlig wird, dann erlaube mir die Frage: "Installierst du dein System in Summe auf eine einzige Partition, oder hast du für /home und ev. für /var und andere Directories oder Subdirectories eigene Partitionen?"

Ich habe wirklich lange experimentiert (sowohl am Rechner als auch mittels Gedankenexperiment) wie man einen Rechner mittels btrfs-Snapshots so organisieren kann, dass er
1. nach einem missglückten Update oder einer missglückten Installation eines Programmes binnen kürzester Zeit wiederhergestellt werden kann
2. Bei einer Wiederherstellung keine Userdaten verloren gehen, sondern diese am aktuellen Stand bleiben - trotzdem das System auf einen früheren Punkt zurückgesetzt wurde.
3. Der User soll auf seine eigenen Daten in Historie einfachst zugreifen können, damit er sich selbst irrtümlich gelöschte/veränderte Dateien wiederherstellen kann, wenn er den Zeitpunkt kennt, wo die Datei noch in Ordnung war.
4. Die Übertragung eines Snapshots soll möglichst wenig Systemressourcen (IO-Last, Netzwerk) beanspruchen.

Ich hab früher mit rsnapshot (basiert auf rsync) gearbeitet. Aber das ist auf älteren Systemen mit großen Datenmengen auf einer HD durchaus unbrauchbar. Selbst mit ionice führte das regelmäßig zu einem unbenutzbaren Rechner, der nur extrem verzögert während des Backups reagierte. Ich war sehr unglücklich damit.

Mit zentral gespeicherten Nutzerdaten hab ich so meine gedanklichen Probleme. Das größte davon ist, wie komme ich an meine Daten, wenn ich kein Netzwerk habe? Szenario: Ich bin auf einer längeren Bahnfahrt mit meinem Laptop unterwegs. Österreich ist ein geologisch durchaus anspruchsvolles Land, moderne Bahnbauten haben grundsätzlich auch in flacheren Gegenden einen hohen Tunnelanteil... Der Empfang in der Bahn ist von endenwollender Qualität. Allein auf der Westbahn von Wien bis St. Pölten hat man bei einer Reisedauer von 30 Minuten knapp 8 Minuten in Summe Mobilfunk-Empfang. Das gilt auch für zugsinterne WLAN-Verbindungen... DAs WLAN ist durchaus durchgängig vorhanden, jedoch nicht darüber hinaus ins Internet - wie denn auch, Wenn kein Mobilfunk den Zug erreicht, kann der genausowenig ins Internet wie wenn ich mein Handy als Modem oder Router missbrauche.

Also gut, ich bin auf Reisen und möchte auf meinem Laptop arbeiten und habe nur unzureichend Internet - wenn meine Daten zuhause auf einem Filserver liegen, zu dem ich mich per VPN verbinden muss, um an sie ranzukommen, kann ich genau in der Nase bohren und sonst nichts tun. Und ich weiß im Vorhinein zwar ungefähr, welche Dateien ich benötige, aber nie exakt... und im Nachhinein die Datenbestände wieder synchronisieren... das ist mir etwas zu aufwändig... Also hab ich meine Daten lieber bei immer am Rechner und ein zweites oder gar drittes Mal auf anderen Geräten (Backup!!)

Ein zentraler Datenspeicher für die /home-Directories ist hingegen durchaus im Büroumfeld sinnvoll, wo ich fixe Arbeitsplätze habe, die sicher immer gute Netzwerkverbindung haben.
Bei uns in der Arbeit wird mit Citrix bzw. Windows Terminal-Server gearbeitet. Sprich die Rechner sind alle irgendwelche Windows-Standardinstallationen, auf deinen ein Client für den virtuellen Desktop gestartet wird. Sowohl fixe PCs als auch Laptops für die Kollegen die in der Gegend herumschwirren.
Unser Internetanbieter hat aber regelmäßig gröbere Schwierigkeiten, eine stabile Netzwerkverbindung am Haupstandort herzustellen und in Außenstandorten sind teilweise durch die Gebäude bedingte sehr schlechte Mobilfunk-Verbindungen. Das führt regelmäßig zu längeren Kaffeepausen, weil mit einer Netzschwankung das Drucken hängt oder der virtuelle Desktop gar nicht mehr erreichbar ist. Die Ersparnisse durch einfache zentrale Wartung und Konfiguration aller Mitarbeiter-Arbeitsplätze frisst der regelmäßige Produktionsausfall durch die Netzschwankungen (mein Arbeitgeber hat schon mehrere Anbieter durch... bei keinem war das Ergebnis dauerhaft zufriedenstellend) aber meiner Meinung nach wieder auf. Zumal auch auf den lokalen Arbeitsplätzen regelmäßig Updates gemacht werden müssen (und wie schon des öfteren auch hier bemängelt, die Windowsupdates sehr rigoros schon mal zu einem 1,5-2-stündigen Ausfall des Arbeitsplatzes führen... besonders bei Win10). Und obwohl virtuelle Desktops eingesetzt werden, kommen vollwertige Rechner zum Einsatz. Die Begründung dafür ist, dass nicht alle Arbeitsplätze gleich sind - auf manchen muss Spezialsoftware für Bildbearbeitung, Zeitungsredaktion oder spezielle Datenbankanwendungen laufen, und die Rechner müssen untereinander austauschbar sein... (nicht meine Verantwortung diese Entscheidung... ich halte diese für nicht klug, und schon gar nicht für kostensparend. Der Dienstleister begründet auf so einem Arbeitsplatz 4GB RAM als das Minimum, da darauf ja Win10 läuft... HDs mit 200GB ohne gestatteter lokaler Speicherung... wie gesagt, nicht meine Entscheidung oder Verantwortung...)

Mit kurzen Worten, ein zentraler Fileserver für die Userdaten steht und fällt mit der Zuverlässigkeit und Verfügbarkeit des Netzes. Und meine persönliche Erfahrung durch intensive Nutzung ist, dass es lästig bis teuer ist, wenn der Fileserver irgendwo in $RECHENZENTRUM steht und nicht am Standort.

Zurück zu den Snapshots vs. Backups.

Ich habe also am lokalen Rechner Snapshots sowohl des Systems, als auch der Userdaten, Emails, Serverinhalte usw.
Mit den Systemsnapshots setze ich den Rechner mit dem Zeitaufwand eines Reboots in einen früheren Zeitpunkt zurück (das geht um ein Hauseck schneller mit Debian als mit Windows und Wiederherstellungspunkt)
Mittels 10-minütiger, stündlicher, täglicher, wöchentlicher usw. Snapshots kann ich dem User anbieten, dass er an vergangene Versionen seiner Dateien und Verzeichnisse über eine einfache Schnittstelle (ein ~/backup -Verzeichnis in seinem Home, wo jeder einzelne Snapshot seiner Userdaten in einem eindeutig benannten Verzeichnis liegt) zugreifen kann um diese bei Bedarf wieder herzustellen. Das funktioniert sowohl in der Shell, als auch in $FILEMANAGER ohne größeren Umweg.

Ein solcher Snapshot ist readonly, das heißt ein Verschlüsselungstrojaner (gibts solche eigentlich auch unter Linux?) kann an den nicht ran. Sollten also die Userdaten so einem Angriff zum Opfer fallen, kann ich sogar diese durch das Umbiegen eines Symlinks oder das gezielte Klonen eines älteren Snapshots und read-write-Setzen wiederherstellen.

Da das Erstellen eines btrfs-Snapshots auf älteren Systemen auch zu Performance-Einbußen führt (wenngleich diese deutlich geringer sind als mit rsnapshot/rsync) kann ich gezielt nur vom System oder den Nutzerdaten oder von beiden zu verschiedenen Intervall-Zeitpunkten einen Snapshot machen. Sprich, nach dem Boot, nach apt upgrade wird ein Snapshot nur vom System-Subvolume gemacht - das merkt der User kaum, und einmal am Tag mache ich am alten System einen Snapshot vom gesamten System. Oder ich mache stündlich einen Snapshot, lasse diesen aber nur nach dem Einstecken des externen Datenträgers einen Snapshot machen, der dann auf diesen übertragen wird.

Ich kann das so durch gezieltes De/Aktivieren der Snapshot-Intervalle an die Gegebenheiten meines Rechners anpassen.
Wenn ich wieder mal an meinen Fotos herumfuhrwerke (Sortieren, Bearbeiten, Umbenennen, Taggen...), dann habe ich in kurzer Zeit viel Veränderung. Dann schalte ich die 10-minütigen Snapshots per Gnome-Extension ein, bin ich mit dem Bearbeiten fertig, schalte ich diese wieder aus. Das hat mich schon einiges an unnötiger doppelter Arbeit oder Suche nach verlorenen Bildern erspart...

Nochmals zurück zu Snapshots vs. Backup.

Am lokalen Rechner mache ich in genannter Art und Weise Snapshots aus den oben sehr ausführlich erklärten Gründen.
Diese Snapshots übertrage ich dann auf externe Datenträger. Dadurch, dass btrfs in der Lage ist, aus zwei Subvolumes (ein Snapshot in btrfs ist nichts anderes als ein weiteres Subvolume) mit dem selben Elternsubvolume die Differenz zu berechnen und nur diese Differenz zu versenden um sie auf einem anderen Datenträger so einzubauen, dass aus dem vorhandenen älteren Snapshot der exakt gleiche jüngere dort entsteht, habe ich am externen Datenträger trotz incrementeller Erstellung vollwertige Backups meines Systems inclusive Deduplikation ohne Hardlinks, da btrfs vorhandene Daten in mehreren Snapshots nur einmal abspeichert.

Wenn ich mich also auf die Snapshots alleine verlasse, kann ich ganz schön auf die Fresse fallen, wenn das Speichermedium den Geist aufgibt. Wenn eine Datei in 100 Snapshots gleich vorhanden ist, ist sie dennoch nur 1x drauf. Ich habe diese eine Datei nur so oft gespeichert, wie ich sie auf verschiedenen Datenträgern gespeichert habe.

Das Schöne an diesen Btrfs-Snapshots ist aber, dass diese vollwertige Klone des Systems darstellen. Folgendes Szenario:
Auf meinem Laptop geht die Festplatte unreparierbar kaputt. Ein Vogel hat im Chemiewerk nebenan etwas gefressen und mir direkt über der HD mit ätzender Kacke ein Loch bis zum Tisch durchgebrannt...
Ich baue eine neue Platte ein, formatiere sie mit btrfs und ziehe mir mit einer Live-ISO mittels des selben Programms womit ich meine Snapshots/Backups erstelle den letzten Snapshot von System und Userdaten (das Programm macht das rekursiv, was die btrfs-progs nicht tun!!!!) nur unter geänderten Pfadangaben für Source und Target auf die Platte.
Die Partition hat vorsorglich die selbe UUID wie die vorhergehende bekommen, oder ich passe in /etc/fstab die UUID an die neue an.

Das Wiederherstellen dauer so lange, wie es eben dauert um 10, 20 oder 500GB an Daten von einem Datenträger auf einen anderen zu kopieren. (Ja, ein System hat so ~10GB, Nutzerdaten oft bedeutend mehr... da ist eine zentrale Speicherung der Nutzerdaten und Mounten mit nfs, cifs oder so wesentlich schneller... Probleme gibts halt an anderer Stelle damit). Bootpartition einrichten, Grub wiederherstellen, UEFI... Und schon arbeite ich an der exakt gleichen Situation weiter, an der mein letzter Snapshot gemacht wurde.

Anderes Szenario:
Ich habe einen Fileserver den ich mit btrfs und genanntem Setup betreibe. Die Platte des Fileservers geht kaputt. Die Backups liegen auf einem anderen Server. Da die Backups voll bootfähige Snapshots meines Fileservers sind, kann ich den anderen Server in so einen Snapshot booten und bin innerhalb weniger Minuten wieder online - Diesmal aber vom Backupserver. Ich kann mich um den Fileserver kümmern, ihn reparieren, Daten versuchen zu retten (wenn wirklich zwischen dem letzten Snapshot und dem Ausfall unwiederbringliches und wichtiges gespeichert wurde) und mit oben genannter Methode den letzten Snapshot vom Backup-Server (den ich gezielt auch Erzeugen kann!!) wieder auf den reparierten Fileserver übertragen und die ggfs. gesicherten Dateien dazuspielen, und bin wieder mit meinem Fileserver online. Der Backupserver übernimmt wieder seine angestammte Funktion als Backupspeicher.

Ich kann auch regelmäßig testen, ob die Backups (nicht nur, aber auch die Snapshots) tatsächlich boot- und korrekt benutzbar sind. Das geht mit btrfs in der Tat ziemlich einfach. Und wer testet schon wirklich, ob die Backups nicht nur gemacht, sondern auch funktionell korrekt sind? Ob incrementelle Backups tatsächlich alle Daten korrekt enthalten?

Ich nutze Linux sehr intensiv und auch die Möglichkeiten, das System anpassen zu können. Natürlich ist eine Standardinstallation was feines, wo ich im Schadensfalle bloß ein Netinstall-Iso am Stick starten muss... Das passt halt auch so gut wie ein Anzug von der Stange. Aber wie fein wäre es - um beim Vergleich zu bleiben - wenn ich meinen Lieblingsanzug, der angemessen wurde, und der schon seine Ausbeulungen an den richtigen Stellen hat um noch perfekter zu sitzen, zu verschiedenen Zuständen einfach klonen könnte. Und wenn ich dann am Baugerüst am Gehsteig hängen bleibe und mir meinen Anzug zerreisse, greif ich einfach in die Aktentasche und hole den gleichen Anzug - sogar mit dem selben Inhalt der Taschen - heraus, zieh in an geh weiter und werfe den kaputten in die nächste Mülltonne.

Das was du machst, ist einen Stangenanzug neu zu kaufen und im Bedarfsfalle die Taschen umräumen. Dabei darfst du aber keine Tasche vergessen...

Wenn ich natürlich einen Fleck von einem ausgeronnenen Kugelschreiber habe, oder mein Kind hat mir in eine Tasche ein klebriges Zuckerl gepickt, dann hab ich das im geklonten ebenfalls... nehm ich halt einen älteren Klon. Die Taxi- und Restaurantrechnung von letzter Woche vom ausufernden Geschäftsessen die ich noch nicht in die Buchhaltung gebracht habe, ist ebenfalls noch drinnen.

LIebe Grüße

scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von TomL » 28.04.2017 11:10:11

scientific hat geschrieben:Wenn dir @TomL beim Gedanken an Subvolumes und Subvolumes in Subvolumes schwindlig wird, dann erlaube mir die Frage: "Installierst du dein System in Summe auf eine einzige Partition, oder hast du für /home und ev. für /var und andere Directories oder Subdirectories eigene Partitionen?"
Ja, natürlich! Nein, natürlich nicht.
scientific hat geschrieben:1. nach einem missglückten Update oder einer missglückten Installation eines Programmes binnen kürzester Zeit wiederhergestellt werden kann
2. Bei einer Wiederherstellung keine Userdaten verloren gehen, sondern diese am aktuellen Stand bleiben - trotzdem das System auf einen früheren Punkt zurückgesetzt wurde.
3. Der User soll auf seine eigenen Daten in Historie einfachst zugreifen können, damit er sich selbst irrtümlich gelöschte/veränderte Dateien wiederherstellen kann, wenn er den Zeitpunkt kennt, wo die Datei noch in Ordnung war.
4. Die Übertragung eines Snapshots soll möglichst wenig Systemressourcen (IO-Last, Netzwerk) beanspruchen.
Das sind alles Punkte, die es bei mir so nicht gibt. Eine missglückte Installation z.B. ist ein Ding der Unmöglichkeit.... weil jede Installation, die ein solches Potential beinhaltet, erst die Laborbedingungen in einer reinen Testumgebung bewältigen muss. Auf die "arbeitenden" Maschinen kommen nur Dinge, von denen ich sicher bin, dass die ausgetestet und korrrekt customized auf Anhieb und völlig ohne Probleme laufen. Und natürlich, das ich bereits vorher mit genügend Kenntnissen für die 'echte' Installation präpariert bin, damit es auch von daher schon gar keine Probleme geben kann.
Zweitens, ich muss mich nicht um die Wiederherstellung von Userdaten kümmern, weil es diese auf den Clients nicht gibt. Drittens, ich habe bisher bei keiner einzigen Maschine Probleme nach einem regulären Upgrade (innerhalb der Debian-Version) gehabt. Ein Upgrade zur nächst höheren Debian-Version schließe ich aus. Wenn ich wechsel, dann nach meinen eigenen Regie-Anweisungen kurzerhand eine neue Installation der neuen Version via cdebootstrap plus Pakete plus Standard-Confs vom Server.... das bereinigt dann auch gleich die alten Leichen.
Mit zentral gespeicherten Nutzerdaten hab ich so meine gedanklichen Probleme. Das größte davon ist, wie komme ich an meine Daten, wenn ich kein Netzwerk habe? Szenario: Ich bin auf einer längeren Bahnfahrt mit meinem Laptop unterwegs.
Ja, das kenne ich. Zum einen habe ich da den Gedankenansatz, dass meine Lebensfähigkeit nicht allein von einer 100%-Verfügbarkeit ALLER unserer Daten abhängig ist. Ich kann also damit leben, wenn ich kurzfristig mal von ALLEM abgeschnitten bin. Darüber hinaus habe ich aber auf meinem Laptop mit maximal ein paar hundert MB kurz vor der Reise die mir wichtigen Daten auf einer LUKS-Partition gespeichert. Alles andere ist via OpenVPN quasi ohne Komfortverlust irgendwann wieder erreichbar. Das reicht mir als Kompromiss-Lösung. Und jetzt mit dem Mail-Server haben wir sogar von Unterwegs wieder Zugang zu unseren gespeicherten Postfächern, neben den aktuellen ISP-Zugriffen via IMAP. Alles zusammen ist also viel mehr, als ich früher unter Windows hatte.

Um das noch mal zu betonen.... ich habe keinen Anspruch auf eine professionelle Lösung und ich kritisiere das auch nicht, wenn jemand anders das tut. Mein Anspruch ist es, die bestmögliche Datensicherheit mit dem geringstmöglichen Aufwand zu haben. Und ich glaube, dass ich dafür und bezogen auf unsere eher unwichtigen Belange eine gut ausgewogene Lösung gefunden habe. Ich will halt nicht etwas nur deshalb tun, weil ich/man es tun kann, sondern nur das, was ich für uns als notwendig erachte. Für andere Umgebungen und Gegebenheiten und Ansprüche mag das natürlich völlig unzureichend sein.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von scientific » 28.04.2017 12:02:29

Ich denke, dass deine Lösung sehr wohl eine durchdachte und gute Lösung ist.

Ich hatte lange eine Systemverschlüsselung mit LUKS/cryptsetup am Laptop und Key auf einem USB-Stick.
Das hab ich aber dann aufgegeben, weil ich keine komfortable Lösung gefunden hatte, die Platte ohne USB-Stick beim Booten als Rückfallebene zu öffnen.
Und was nützt mir ein 2048 Byte großer Key, wenn ich erst recht ein "Backdoor" mit einem Passwort in merkbarer Länge habe.
Au#erdem muss ich den Laptop runterfahren und kann ihn nicht einfach schlafen schicken... Schläft er, bleibt die Platte ja aufgesperrt...

Was bei mir definitiv noch ansteht ist ein expliziter Miniserver daheim. Wie ich mir sagen ließ, ist ein Raspi aber als File- und Mailserver aufgrund der geringen Datendurchsatzraten am USB-Controller nicht geeignet. Ein ausgewachsenes NAS braucht hingegen zuviel Energie...

Das wird eines meiner nächsten Projekte.

Dann muss ich mein Backupskript dank dann vorhandener Testmöglichkeit noch um Netzwerkfähigkeit erweitern. Vorgesehen hab ichs ja schon im Konzept.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von TomL » 29.04.2017 20:42:14

scientific hat geschrieben:Was bei mir definitiv noch ansteht ist ein expliziter Miniserver daheim. Wie ich mir sagen ließ, ist ein Raspi aber als File- und Mailserver aufgrund der geringen Datendurchsatzraten am USB-Controller nicht geeignet. Ein ausgewachsenes NAS braucht hingegen zuviel Energie...
Wie so oft im Leben ist auch hier alles relativ..... sowohl die persönliche Bewertung von Resultaten als auch die Gewichtung von Faktoren. Und gerade die Relation von Stromverbrauch des Servers zu Relevanz für unser Leben ist für mich ein Faktor mit extrem hoher Gewichtung. Ich habe vier Pi's, zwei ausgemusterte Model B+ (700 Mhz), die heute meine Test-Maschinen sind, einer mit GUI, der andere ohne. Und zwei 'produktive' Modell 2 B+ (900 Mhz Quadcore).

Von den beiden neueren arbeitet einer als Server, mit folgenden Aufgaben:
- Fileserver
- Printserver (RAW-Mode ohne Rendering-Treiber, rendern tun die Clients selber)
- OpenVPN-Server (sowohl integrierend ins LAN als auch durchleitend ins Internet für sicheres Surfen)
- Backup-Server (oder besser komplexe Backup-Services)
- Mailserver (neuerdings)
- CardDav/CalDav-Server (schon lange)

Mit keiner dieser Aufgaben ist er bei uns überfordert oder frustet die Anwender mit Lahmarschigkeit.... ganz im Gegenteil, z.B. ist das Arbeiten mit Thunderbird und IMAP-Mails vom Dovecot- Server gefühlsmäßig nicht viel langsamer, als würde ich das lokal machen. Er hat zwei Platten als Langzeitspeicher anschlossen und eine Crucial 256-GB-SSD als Datenspeicher für die schnell-verfügbar-sein-sollenden täglichen Bewegungsdaten und der persönlichen Daten aus den User-Homedirs. Die HDs schalten sich aus Stromspargründen schnell ab und pennen eigentlich fast den ganzen Tag. Die SSD rsync'ed sich täglich einmal auf einer der Platten. Unser PI hat keine Probleme damit gleichzeitig mehreren lokalen smplayern oder VLCs oder Deadbeefs Filmfiles oder Musikfiles per Samba zur Verfügung zu stellen. Da schlägt die CPU-Last kaum aus. Die Arbeit mit auf dem Server gespeicherten Office-Dokumenten ist kaum langsamer als beim lokalen Arbeiten. Also, mit anderen Worten, den ganz normalen alltäglichen Familienwahnsinn, mit normalen Familienmitgliedern, von denen keiner ein IT-aggressiver Power-User ist, schafft unser PI ohne ein einziges mal aus der Puste zu geraten, Schluckauf zu bekommen oder die Leute mit Wartezeiten zu nerven. Man merkt kaum, dass die Daten vom Server und seiner SSD kommen.

Ganz klar hat der PI natürlich auch schnell seine Grenzen erreicht.... je nachdem, mit welcher Erwartung man da dran geht. Ich installiere den PI, bring ihn ins Netz und teste als erstes ne 32 GB große Variante von Lang's Metropolis von A über Netz nach B auf den PI zu kopieren. Danach habe ich garantiert keinen Bock mehr auf PI und Konsorten, weil man wahrscheinlich erst mal über Paris das nächste McDonalds ansteuern kann und sich 4 Frust-BigMacs reinpfeift.... und fertig ist der PI danach immer noch nicht. Und wenn ich als erstes auf die Idee käme, mal nen 4k-Fim zu streamen, nehme ich anschließend wohl nen Vorschlaghammer und reduziere den PI auf Briefmarken-Stärke. Das kann er nämlich auch nicht. Wegen seinem geteilten Controller (USB und LAN) und der nur 900 MHz sind solcherart Grenzen aber vorher bekannt und Enttäuschung wegen nicht erfüllter Erwartungshaltung ist einfach nur Dummheit. Und das er mit seinen 900 Mhz kein Schnellmerker oder -Rechner ist, ist auch kein vorher verschwiegenes Geheimnis.

Aber... seine Grenzen schließen nicht aus, dass man ihn nicht trotzdem total sinnvoll täglich nutzen kann. Und man kann mit Organisation und Planung einige seiner Schwächen prima kompensieren. Wenn ich beispielsweise "fette" Files in 2-stelliger GB-Größe kopieren muss, so warte ich nicht aufs fertigwerden, sondern starte den Job nachts in "screen" und geh anschließend pennen. Bein nächsten Blick auf den Rechner ist er fertig, ohne dass ich genervt auf den Bildschirm gestarrt habe und meine Laune sinkt, weils dauert und dauert und dauert. Und wenn ich als Einmal-Aktion mal wirklich viel habe, z.B. ein ganze Platte umschaufeln, so umounte ich die Platten und mache das an meinem PC. Wenn ich 10-15 GB Osmand-Karten aktualisieren möchte, mach ich das auch nicht über den Server, sondern lokal über meinen PC.
Der zweite PI, der nix anderes als den JDL2 bedient, läuft per Scheduler nielmals vor 1 oder 2 Uhr nachts an, weil der eben keine eigene Platte hat und deshalb natürlich auch den Server nutzt. Mit Rendern (beim Druck) würde ich meinen PI nie quälen, denn dabei läuft er minutenlang bei 100% CPU-Last... und natürlich geht dann nix anderes mehr... also deshalb lokale (Client-)Druckertreiber. Bei solcherart Druck mit RAW an den Drucker durchgeleiteten Daten schlägt seine CPU-Last noch nicht mal aus.

Riesen-Datenmengen kann er nicht schaufeln.... ebensowenig wirkliche rechenintensive Aufgaben befriedigend erfüllen. Aber genau das kommt bei uns im Familienbetrieb eh kaum vor. Ich bewahre ihn deshalb vor den eher seltenen "schwergewichtigen" Aufgaben und lasse ihn nur das tun, was er wirklich gut kann, nämlich das normale tägliche Familiengeschäft zu handeln. Für alles andere gibt es leistungsfähigere Alternativen im Haus. Diese Organisation verhindert Frust und spart aufs Jahr trotzdem einiges an Stromkosten eines "stärkeren" Servers. Für uns ist der PI der perfekte Kompromiss... einen 24/7-Server zu haben, der trotzdem kein Stromfresser ist. Da nehme ich die Schwächen gerne in Kauf. BTW, die Chefin und beste Ehefrau der Welt ist immer noch der Meinung, dass sie (mit Debian) nur ein "anderes" Windows hat und bezüglich ihres sehr laienhaften Umgangs mit ihren PCs immer noch keinen Unterschied hinsichtlich Komfort im Vergleich zu unserem alten Windowsserver bemerkt hat. Und selbst ihr wirklich alter Dell D620-Läppi, dessen Tausch und Ausmusterung sie bereits mehrfach abgelehnt hat, läuft mit Debian und Daten übers Netz sowas von klasse....dass ich immer wieder erstaunt bin. Allerdings werde ich dem jetzt auch noch eine SSD spendieren.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von Lord_Carlos » 29.04.2017 22:19:58

scientific hat geschrieben: Au#erdem muss ich den Laptop runterfahren und kann ihn nicht einfach schlafen schicken... Schläft er, bleibt die Platte ja aufgesperrt...
Wie greift man das an?
Ist das nicht auf der ebene von ram einfrieren und aehnliches? Also wirklich komplex?
Laeufst du gefahr mit sowas angegriffen zu werden?
scientific hat geschrieben: Was bei mir definitiv noch ansteht ist ein expliziter Miniserver daheim. Wie ich mir sagen ließ, ist ein Raspi aber als File- und Mailserver aufgrund der geringen Datendurchsatzraten am USB-Controller nicht geeignet. Ein ausgewachsenes NAS braucht hingegen zuviel Energie...
An guten tagen soll man wohl 11MB/s schaffen koennen. Selber aber nicht getestet.

Wie viel ist zu viel Energi fuer dich?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

TomL

Re: System Go Back ala Windows Recovery oder ähnl.?

Beitrag von TomL » 30.04.2017 11:13:40

Lord_Carlos hat geschrieben:
scientific hat geschrieben:Ein ausgewachsenes NAS braucht hingegen zuviel Energie...
Wie viel ist zu viel Energi fuer dich?
Gerade zu dem Thema habe ich eine eigenwillige, aber durch Erfahrungen gewachsene Meinung. Mich interessieren die Energiekosten für die tatsächliche Nutzung eher weniger. Ich "konsumiere" diesen Service, also muss ich dafür bezahlen. Es ist ähnlich wie beim Auto.... ich mag gerne eine gewisse Größe, also denke ich nicht über den Verbrauch nach... ich "konsumiere" diesen Komfort, also muss ich dafür bezahlen. Ich hätte aber beim Auto ein echt großes Problem damit, wenn ich auch hohe Spritkosten hätte, während das Auto in der Garage steht. Für eine Nicht-Leistung trotzdem zu bezahlen...?... nee, dazu bin ich nicht bereit.

Genau so sehe ich das bei unserem Server. Ich lehne es ab, für Zeiten, in denen wir das IT-Equipment nicht nutzen und keinen gefühlten Komfort/Vorteil davon haben, trotzdem Geld zu bezahlen... also Geld zu bezahlen, ohne eine Gegenleistung zu erhalten. Und deshalb versuche ich mit Hinnahme von Einbußen bei der Leistungsfähigkeit diese unvermeidbaren Kosten (auch mit einem Auge auf die Umwelt geschielt) auf ein Minimum zu senken.

Mein damaliger Windows-Server (zu der Zeit unvernünftig überdimensioniert) hatte eine Ruhelast von ~100 W, wobei der Verbrauch bei Volllast auch schon mal auf 150-170 W ansteigen konnte. Mein PI hat heute bei Volllast einen Verbrauch von 10 W, wenn alles pennt, vermutlich jedoch 1/3 weniger. Eine einfache Milchmädchenrechnung mit den leicht nachvollziehbaren Werten 10W und 100W sieht dann so aus:

Code: Alles auswählen

10      W       100
240     W/T     2400
7200    W/M     72000
86400   W/J     864000
86,4    KW/h    864
24,19   0,28 €  241,92

        6h
 6,05   €/25%    60,48
18,14   €/75%   181,44
Wenn ich unterstelle, dass wir unser IT-Equipment im Jahresdurchschnitt vielleicht täglich 6h nutzen, dann zahle ich 3/4 des Tages Stromkosten, ohne eine Gegenleistung dafür zu erhalten. Ich glaube aber, dass es nicht mal einschließlich der nächtlichen Services auf ein Jahresmittel von 6h/T kommt. Im Endergebnis bin ich also nicht mehr bereit, jährlich etwa 181 € mit steigender Tendenz zu bezahlen, ohne eine Gegenleistung dafür zu bekommen. Die reinen Bereitstelllungsgebühren von 18 €/J für den PI und seiner 3 Platten sind unvermeidbar, aber erträglich. Ich bin sicher, dass es -im Vergleich zum PI- bestimmt leistungsfähigere Geräte gibt, die keine 100 W verbrauchen. Aber selbst die Hälfte meiner 181 € wäre mir zuviel, wenn ich nix dafür erhalte, außer der Tatsache, dass das Equipment verfügbar ist. Und wie ich oben schon sagte, die schwache Leistung eines PIs ist nur dann auch tatsächlich eine zu schwache Leistung, wenn ich/wir sie als störend wahrnehmen.... und genau das trifft hier bei uns nicht zu.

Antworten