Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #131374 > unrolled thread

USB-Automatik

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-14 17:52 +0200
    Re: USB-Automatik Joerg Lorenz <hugybear@gmx.ch> - 2023-06-14 18:23 +0200
      Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-14 19:09 +0200
        Re: USB-Automatik Arno Lutz <invalid@freakmail.de> - 2023-06-14 20:41 +0200
          Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-14 21:35 +0200
            Re: USB-Automatik "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-15 02:20 +0200
              Re: USB-Automatik Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-15 06:38 +0000
                Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-15 14:14 +0200
                  Re: USB-Automatik Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-15 13:29 +0000
                    Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-15 16:53 +0200
                      Re: USB-Automatik Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-15 20:29 +0000
                        Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-16 02:03 +0200
                  Re: USB-Automatik Tim Ritberg <tim@server.invalid> - 2023-06-15 15:48 +0200
                  Re: USB-Automatik Joerg Lorenz <hugybear@gmx.ch> - 2023-06-15 19:44 +0200
                    Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-15 19:54 +0200
                  Re: USB-Automatik Tim Ritberg <tim@server.invalid> - 2023-06-15 22:21 +0200
                  Re: USB-Automatik Marcus Jodorf <m@bogomips.de> - 2023-06-16 01:38 +0200
                    Re: USB-Automatik Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-16 05:52 +0000
                    Re: USB-Automatik Christian Garbs <mitch@cgarbs.de> - 2023-06-16 07:07 +0000
                      Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-16 11:44 +0200
                        Re: USB-Automatik Christian Garbs <mitch@cgarbs.de> - 2023-06-18 11:17 +0000
                      Re: USB-Automatik SimplyNews <Simply.News@gmx.de> - 2023-06-16 19:26 +0200
                        Re: USB-Automatik Marcus Jodorf <m@bogomips.de> - 2023-06-17 22:51 +0200
                        Betreffwechsel bei Themenwechsel erwünscht? (was: USB-Automatik) Helmut Waitzmann <nn.throttle@xoxy.net> - 2023-06-17 23:27 +0200
                        syncthing für große Backups (was: Re: USB-Automatik) Christian Garbs <mitch@cgarbs.de> - 2023-06-18 09:57 +0000
                    Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-16 11:38 +0200
                      Re: USB-Automatik "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-16 17:34 +0200
                        Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-16 18:30 +0200
                          Re: USB-Automatik Christian Garbs <mitch@cgarbs.de> - 2023-06-18 10:04 +0000
                      Re: USB-Automatik Marcus Jodorf <m@bogomips.de> - 2023-06-17 23:04 +0200
                      Re: USB-Automatik Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-06-18 12:01 +0200
                        Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-19 10:14 +0200
                    Re: USB-Automatik Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-16 12:18 +0000
                      Re: USB-Automatik Wolfgang Bauer <wolfgang-bauer@mein.gmx> - 2023-06-16 14:30 +0200
                  Re: USB-Automatik Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-06-16 12:40 +0200
    Re: USB-Automatik Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-06-14 18:32 +0200
      Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-14 19:20 +0200
        Re: USB-Automatik SimplyNews <Simply.News@gmx.de> - 2023-06-15 16:42 +0200
          Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-15 17:02 +0200
          Re: USB-Automatik "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-15 18:37 +0200
            Re: USB-Automatik SimplyNews <Simply.News@gmx.de> - 2023-06-16 18:29 +0200
              Re: USB-Automatik "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-17 09:20 +0200
              Re: USB-Automatik Marcus Jodorf <m@bogomips.de> - 2023-06-17 21:49 +0200
    Re: USB-Automatik SimplyNews <Simply.News@gmx.de> - 2023-06-15 16:29 +0200
      Re: USB-Automatik SimplyNews <Simply.News@gmx.de> - 2023-06-15 16:55 +0200
        Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-15 17:22 +0200
          Re: USB-Automatik SimplyNews <Simply.News@gmx.de> - 2023-06-15 17:34 +0200
            Re: USB-Automatik Matthias Gerds <m.gerds@posteo.de> - 2023-06-15 18:37 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#131525

Mahlzeit!

Matthias Gerds <m.gerds@posteo.de> wrote:
> Am 16.06.23 um 09:07 schrieb Christian Garbs:

>> Der große Unterschied zu Snapshots/borg/restic und Co. ist, dass
>> syncthing Änderungen erkennt und sofort in Aktion tritt, statt z.B.
>> nur alle 15 Minuten in Aktion zu treten.
> 
> Hatte ich auch mal ausprobiert. Mein Anliegen war vor allen Dingen, 
> Adress-, Passwort-DB und andere Kleinigkeiten zu synchronisieren. Leider 
> hatte ich dann festgestellt, dass das auf dem Mobilgerät auch viel Strom 
> verzehrt. Vielleicht ist das ja heute anders?

Mobile Endgeräte habe ich noch nicht getestet, nur PCs.
Auf meinem eher schnarchigen Laptop war das durchaus benutzbar.

> Fand es auch nicht so einfach, das zu konfigurieren.

Lag das an der Mobil-Seite oder war das früher anders?

Am PC installierst Du das, gehst in die lokale Weboberfläche und
trägst dann eigentlich nur noch die Keys/ID der gewünschten Gegenseite
ein.  Dann auf einem der beiden Geräte einen lokalen Ordner freigeben
(drei Klicks oder so) und die auf dem anderen Gerät aufpoppende
Meldung "XY möchte Z mit Dir teilen, ist das OK?" bestätigen.

Mehr ist das nicht.

Wenn man "unter sich" bleiben will, muss man irgendwo noch einstellen,
dass er die öffentlichen Server nicht nehmen soll und ggf. IP-Adressen
von Hand konfigurieren.  Das habe ich vor Ewigkeiten einmalig gemacht,
war auch nicht groß wild, das läuft bei mir seitdem komplett VPN-intern.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Human beings were created by water to transport it uphill.

[toc] | [prev] | [next] | [standalone]

#131469

Hallo,


Am 16.06.23 um 09:07 schrieb Christian Garbs:
> Mahlzeit!
> 
> Marcus Jodorf <m@bogomips.de> wrote:
>> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>>
>> Das scheint mir fast aufwendiger, als auf bewährte Mechanismen zu
>> setzten, also z.B. rsync-basierende tools oder modernere wie borg oder
>> restic. Dann kann man auch nicht so leicht Sachen vergessen zu sichern.
> 
> Da will ich noch syncthing in den Ring werfen:
> 
> [...]
> 
> Der große Unterschied zu Snapshots/borg/restic und Co. ist, dass
> syncthing Änderungen erkennt und sofort in Aktion tritt, statt z.B.
> nur alle 15 Minuten in Aktion zu treten.

Das ist interessant, weil wir die Frage, wie man eine Liste der 
geänderten und neuen Dateien (eines Verzeichnisses u/o eines 
Dateisystems) -- und nur von diesen! -- erhalten kann, erst in dem 
Thread "inkrementelles Backup mit Snapshots" hatten.

Es kam u.a. heraus, dass auch ein btrfs-send keinen 'differentiellen 
Snapshot' erzeugt, sondern nur mit Hilfe eines Eltern-Snapshots (Option 
'-p') sozusagen differentiell überträgt, aber auf der Empfangsseite 
(btrfs-receive) den Snapshot komplett rekonstruiert. Es wäre aber 
wenigstens die o.g. Liste erwünscht gewesen.

Kannst Du uns sagen, ob syncthing vielleicht auch alle Änderungen (neue 
+ geänderte Dateien) über einen gewissen Zeitraum irgendwie verwertbar 
auswerfen kann?

Noch eine Frage: arbeitet syncthing ausschließlich auf diese instantane 
Weise, oder macht es Sinn, es durch einen Cronjob zu bändigen, wenn man 
nicht andauernd syncen lassen will?

Danke für die Auskunft!


Gruß, Tom


P.S:
Allgemeine Frage: ist das Forken bei einem neuen Thema erwünscht hier? 
Wir sind ja -- SCHON WIEDER, möchte man fast sagen ;-) -- inzwischen 
beim allgegenwärtigen Backup angekommen. Find' ich ja ganz ok :-)

[toc] | [prev] | [next] | [standalone]

#131496

SimplyNews <Simply.News@gmx.de> schrieb:

> Das ist interessant, weil wir die Frage, wie man eine Liste der
> geänderten und neuen Dateien (eines Verzeichnisses u/o eines
> Dateisystems) -- und nur von diesen! -- erhalten kann, erst in dem
> Thread "inkrementelles Backup mit Snapshots" hatten.

zfs diff zroot/ROOT/debian@snap_20230617_154302_000 zroot/ROOT/debian@snap_20230617_164302_000 
M	/var/lib/dhcp/dhclient.enp1s0f0.leases
M	/tmp
+	/var/lib/samba/dhcp.conf
+	/tmp/systemd-private-f338099a2a40470b8690fcf892e90ed8-systemd-hostnamed.service-I8Xdrs
+	/tmp/systemd-private-f338099a2a40470b8690fcf892e90ed8-systemd-hostnamed.service-I8Xdrs/tmp
+	/var/tmp/systemd-private-f338099a2a40470b8690fcf892e90ed8-systemd-hostnamed.service-VtpDGn
+	/var/tmp/systemd-private-f338099a2a40470b8690fcf892e90ed8-systemd-hostnamed.service-VtpDGn/tmp
-	/var/lib/samba/dhcp.conf
M	/var/lib/samba

> Es kam u.a. heraus, dass auch ein btrfs-send keinen 'differentiellen
> Snapshot' erzeugt, sondern nur mit Hilfe eines Eltern-Snapshots
> (Option '-p') sozusagen differentiell überträgt, aber auf der
> Empfangsseite (btrfs-receive) den Snapshot komplett rekonstruiert. Es
> wäre aber wenigstens die o.g. Liste erwünscht gewesen.

Ich vermute, Du hast das noch nicht völlig verstanden.

Ein Snapshot stellt immer ein komplettes Filesystem zu einem bestimmten
Zeitpunkt dar, wenn man die Inhalte sichtbar macht. Ein Snapshot selber
ist nur ein Abbild der Metadaten zum Zeitpunkt X.
Das heißt jeder Snapshot, den Du mountest bzw. dessen Inhalte Du
sichtbar machst, zeigt Dir immer das gesamte Filesystem zum gegebenen
Zeitpunkt. Das liegt in der Natur der Sache von Snapshots.

Um von den Inhalten von Zeitpunkt A auf Zeitpunkt B zu kommen, reicht
natürlich einfach die Differenz der Daten. Wir reden hier von COW
Filesystemen - da ist intern quasi ohnehin alles nur Differenzen der
Metadaten.
Insofern wird da nicht wirklich etwas „rekonstruiert“.

Du überträgst den Snapshot vom Zeitpunkt A auf einen anderen Rechner. Da
dort noch nichts ist, muß Snapshot A eine volle Kopie des Filesystems
sein. Metadaten und alle Datenblöcke.
Zum Zeitpunkt B überträgst Du wieder einen Snapshot. Da Snapshot A schon
am Ziel vorhanden ist, reicht es, die Differenz zwischen Snapshot A und
B zu übertragen (also neues Abbild der Metadaten zum Zeitpunkt B und die
geänderten Datenblöcke zwischen A und B) und Du hast dann auch auf dem
Ziel beide Snapshots. Da wird allerdings nichts „rekonstruiert“, sondern
quasi nur die geänderten Datenblöcke ins Filesystem eingebaut und die
neuen Metadaten abgespeichert, denn auch auf der Quelle sind die ganzen
Snapshots einfach nur die Differenzdaten bzw. Abbilder der Metadaten zu
einem Zeitpunkt X.

Deshalb geht das auch alles „instant“.
Wenn B als Differenz auf dem Ziel angekommen ist, dann ist dort Snapshot
B sofort vollwertig vorhanden. Du kannst dann auch auf dem Ziel einfach
A löschen und B ist dennoch immer noch vollständig vorhanden. Weil wenn
Du A löschst, wird nur das Abbild der Metadaten zum Zeitpunkt A
gelöscht.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#131501 — Betreffwechsel bei Themenwechsel erwünscht? (was: USB-Automatik)

 SimplyNews <Simply.News@gmx.de>:

> Allgemeine Frage: ist das Forken bei einem neuen Thema erwünscht 
> hier?

 Du meinst, ob der Betreff beim Themenwechsel im Rahmen einer 
 Diskussion angepasst werden sollte?  Meiner Meinung nach ja, 
 unbedingt.  Das ermöglicht es Leuten, die nur entweder am alten 
 oder nur am neuen Thema interessiert sind, auf den entsprechenden 
 Betreff zu filtern. 

[toc] | [prev] | [next] | [standalone]

#131519 — syncthing für große Backups (was: Re: USB-Automatik)

Mahlzeit!

SimplyNews <Simply.News@gmx.de> wrote:
> Am 16.06.23 um 09:07 schrieb Christian Garbs:

>> Da will ich noch syncthing in den Ring werfen:

[…]

> Kannst Du uns sagen, ob syncthing vielleicht auch alle Änderungen (neue 
> + geänderte Dateien) über einen gewissen Zeitraum irgendwie verwertbar 
> auswerfen kann?

Syncthing arbeitet entweder mit einem manuellen Crawl der
konfigurierten Verzeichnisstruktur alle X Zeiteinheiten (das ist doof
und langsam) oder mit sowas wie inotify (schneller, besser, toll).

Inotify haben wir in dem Backup-Thread bereits durchexerziert, ich
meine, das Ergebnis war "so viele Dateien kann der Kernel nicht
parallel beobachten".

Falls doch: Mach inotify ohne syncthing :-P

(Schau mal hier rein: https://docs.syncthing.net/users/syncing.html
 Tatsächlich macht Syncthing eine Mischung aus "full scans" und
 "watcher".  Der "watcher" kann abgeschaltet werden.)


Zur eigentlichen Frage: Theoretisch kommt man da vielleicht irgendwie
dran, das Ding hat eine API.  Es kann aber nicht zaubern: Beim
Programmstart wird es einmal alle Dateien "scannen", also komplett
einlesen und den Dateiinhalt hashen.  Das dauert dann ungefähr genauso
lang, als wenn Borg das macht (Du hast glaube ich immer noch nicht
gemessen, wo Borg trödelt - beim Einlesen der Dateien, beim Abgleich
der Hashes mit dem Repository oder beim Übertragen der Änderungen ins
Repository).

Sowas kannst Du Dir auch einfach selbst bauen (find + sha256sum +
diff).  Wird prinzipbedingt nicht schneller, aber vielleicht kann es
direkt auf dem NAS laufen ohne Netzwerkzugriff.


> Noch eine Frage: arbeitet syncthing ausschließlich auf diese instantane 
> Weise, oder macht es Sinn, es durch einen Cronjob zu bändigen, wenn man 
> nicht andauernd syncen lassen will?

Es ist nicht dafür gedacht, aber Du kannst es starten und stoppen, es
holt dann nach einem initialen "full scan" Synchronisationen nach.
Das passiert z.B. zwangsläufig bei mir am Laptop so, der wird nur alle
paar Tage für ein paar Stunden gebootet.  Wenn der "full scan" wegen
Deiner Datenmenge aber 6 Stunden braucht, wirst Du keinen Spaß daran
haben.

Es bietet vermutlich sich an, bei vielen "sometimes on"-Geräten einen
zentralen Rechner durchlaufen zu lassen, damit a) immer ein
Sync-Partner da ist und b) die Reihenfolge der Änderungen klar ist,
wenn mehrere Geräte in Abwesenheit der anderen aufwachen.

Aber in Deinem Fall dürfte das egal sein, bei Dir wäre ja das Backup
dauerhaft online und der Echt-Server würde ab und zu online kommen.
Der wird dann aber auch erstmal alle Dateien scannen müssen – die
kommen ja von Deinem NAS, also wird es wieder langsam.  Kannst Du
vielleicht syncthing am NAS laufen lassen?  Aber dann hat das
bestimmt zu wenig RAM…

Ich weiß aber nicht, wieviel Speicher das bei Deiner Datenmenge
braucht.  Andererseits kann syncthing grundsätzlich mit großen
Datenmengen umgehen: Es gibt Statistiken für die Nutzung über die
öffentlichen Server unter https://data.syncthing.net/

Wenn Du da unter "Percentile" guckst, ist der größte gesyncte
Datenbestand 293 TB und das größte einzelne Verzeichnis hat 153TB.

> Allgemeine Frage: ist das Forken bei einem neuen Thema erwünscht hier? 
> Wir sind ja -- SCHON WIEDER, möchte man fast sagen ;-) -- inzwischen 
> beim allgegenwärtigen Backup angekommen. Find' ich ja ganz ok :-)

Ich weiß nicht, was Du mit forken meinst, aber das Subject könnten wir
mal anpassen, klar.  Passiert hier eher selten, aber die Newsgruppe
ist ja insgesamt auch ganz übersichtlich, da kennt man eh jeden Thread
mit Vornamen ;-)

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Tall, dark and handsome Prince seeking his one true love.  Hair styled
in odangos are a plus.  Non-members of the Silver Millenium need not
apply.  Email endymion@serenity.moon.gov for an on-line application.

[toc] | [prev] | [next] | [standalone]

#131459

Am 16.06.23 um 01:38 schrieb Marcus Jodorf:
> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
> 
>> Datensicherungen sollen ja beispielweise gegen Hardware-Ausfälle
>> absichern. Aber bei mir ist das häufigste Problem, daß ich
>> selber eine Datei durch normale Bearbeitung verändert oder
>> versehentlich gelöscht habe und dann eine Version brauche,
>> die praktisch von gestern oder der vorigen Woche ist.
>>
>> Dazu habe ich inzwischen die häufigsten Programme, welche ich
>> zur Dateibearbeitung verwende (Texteditoren, Textverarbeitungen,
>> Tabellenkalkulationen) so umgebaut, daß sie beim Öffnen oder
>> Schließen einer Datei noch eine Sicherungskopie, deren Name einen
>> aktuellen Zeitstempel enthält, in eine separaten Ordner speichern.
>> Das sammelt sich alles in einem großen Ordner, in dem ich dann
>> ab und zu ältere Kopien löschen muß.
>>
>> So kann ich bei den wichtigsten bearbeiteten Datei immer noch einmal
>> deren Zustände aus den Vortagen oder Vorwochen wieder sehen.
>>
>> Man kann das auch als primitives selbstgebaute Time Machine /
>> Timeshift / VCS ansehen. Ich brauche es zirka einmal wöchentlich.
> 
> Das scheint mir fast aufwendiger, als auf bewährte Mechanismen zu
> setzten, also z.B. rsync-basierende tools oder modernere wie borg oder
> restic. Dann kann man auch nicht so leicht Sachen vergessen zu sichern.

Na ja, Nachteil dieser speziellen Backup-Lösungen ist doch, dass man 
diese dann auch immer benötigt, wenn man auf seinen eigenen Rechner 
nicht mehr zugreifen kann. Das kann mit GRSYNC o.ä. nicht passieren. Die 
Daten liegen schlicht als Kopie vor.
Allerdings hat man als Linux-Benutzer erfahrungsgemäß noch das Problem, 
dass man seine Daten in fremder Umgebung (Windows  o.ä.) wegen eines 
meist inkompatiblen Dateissystems (ext4 vs. exFAT) schlecht einlesen 
kann. Und Sichern auf (ex)FAT geht auch nicht, da fehlen dann die ganzen 
versteckten Daten als auch Dateien mit inkompatiblen Zeichen im 
Dateinamen (z.B.'?' usw.). Alles schon durchprobiert.

> Damit kannst Du relativ bequem und vor allem vollautomatisch Sicherungen
> auf andere Rechner oder zu entsprechenden externen Dienstleistern oder
> auch nur lokal (entspräche hier Deinem bisherigen Vorgehen) erstellen.
> 
> Traditionell habe ich da z.B. lange dirvish basierend auf rsync
> verwendet.
> Aus Effizienzgründen verwende ich heute bei Rechnern, wo Inhalte sich
> häufiger ändern, dann z.B. borg. Wenn der Laptop z.B. im Heimnetz
> eingebucht ist und den Homeserver erreichen kann, dann schiebt der alle
> drei Stunden eine Sicherung mit borg auf den Homeserver.

Und wenn der Schädling erst einmal im System ist, dann ist er auch ganz 
schnell auf Deinem Homeserver.

> Mit modernen Filesystemen (zfs, btrfs) wird es mit Snapshots noch
> effizienter:
> Meine Workstation hier macht z.B. alle 10 Minuten einen Snapshot, und
> dünnt das dann über die Zeit aus, so daß jeweils alle
> 10-Minuten-Snapshots der letzten Stunde vorhanden sind, jeweils 1
> Snapshot pro Stunde der letzten 3 Tage, Tagessnapshots des letzten
> Monats, Monatssnapshots des letzten halben Jahres. Alles ganz nach
> Belieben.
> Einmal pro Stunde wird das zusätzlich auf den Homeserver gesynct. Das
> geht hier dank der Snapshots in wenigen Sekunden.
> Auf alle Snapshotinhalte kann man problemlos sofort read-only zugreifen,
> falls man mal einzelne Sachen wiederherstellen muß. Ein diff zeigt einem
> dabei auch sofort an, welche Dateien zwischen zwei beliebigen
> Snapshotversionen jeweils überhaupt geändert wurden.
> 
> Oder man kann natürlich ein komplettes rollback machen und das
> Quelldateisystem komplett daraus wieder herstellen.
> 
> Zusätzlich werden über hooks in apt auch noch jedesmal snapshots von
> allen davon berührten Volumes (Abgleich installed files der Pakete mit
> lokalen Pfaden/Volumes) gemacht, sobald ein Paket installiert oder
> deinstalliert wird. Das heißt, sollte da mal was schiefgehen, reicht ein
> rollback und die Packetinstallation/Upgrade hat nie stattgefunden.
> (Für den selteneren Fall, daß ein Paketupdate Sachen geändert hat, die
> nicht von der file list im Paket abgedeckt werden, hat man immer noch
> die regulären Snapshots, die das ganze System abdecken).

Klingt gut, muss ich mir mal ansehen. Bis dahin setze ich für 
persönliche Daten nach wie vor auf externe Platten (die eben nicht 
ständig erreichbar sind). Das ist zugegebenermaßen sehr unpraktisch und 
auch keine besonders elegante Lösung, weil die Fehlerquelle (ein Hoch 
auf das Vergessen) auch meist vor dem Computer sitzt. :-)

Den Rest (System) erledigt Timeshift.

> Echtes Backup ist natürlich noch einmal unabhängig davon aber gerade
> gegen die Fälle von Benutzerfehlern, Fehlern bei Updates usw. kann man
> sich relativ gut und bequem mit solchen Mechanismen absichern.
> Da reichen wie gesagt schon Sachen basierend auf
> rsync/borg/restic/usw. für das Wesentliche.
> Entscheidend ist dabei, daß es voll automatisiert und damit regelmäßig
> und tatsächlich stattfindet.

Wahrscheinlich ist eine Mehrfachabsicherung mit verschiedenen Lösungen - 
u.a. wie von Dir beschrieben - noch die beste Herangehensweise.

M:

[toc] | [prev] | [next] | [standalone]

#131465

On 2023-06-16 09:38, Matthias Gerds <m.gerds@posteo.de> wrote:
> Am 16.06.23 um 01:38 schrieb Marcus Jodorf:
>> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>> 
>>> Datensicherungen sollen ja beispielweise gegen Hardware-Ausfälle
>>> absichern. Aber bei mir ist das häufigste Problem, daß ich
>>> selber eine Datei durch normale Bearbeitung verändert oder
>>> versehentlich gelöscht habe und dann eine Version brauche,
>>> die praktisch von gestern oder der vorigen Woche ist.

Nicht nur bei Dir. Meiner Erfahrung nach ist das bei weitem der
häufigste Fall.


>>> Dazu habe ich inzwischen die häufigsten Programme, welche ich
>>> zur Dateibearbeitung verwende (Texteditoren, Textverarbeitungen,
>>> Tabellenkalkulationen) so umgebaut, daß sie beim Öffnen oder
>>> Schließen einer Datei noch eine Sicherungskopie, deren Name einen
>>> aktuellen Zeitstempel enthält, in eine separaten Ordner speichern.
>>> Das sammelt sich alles in einem großen Ordner, in dem ich dann
>>> ab und zu ältere Kopien löschen muß.
>>>
>>> So kann ich bei den wichtigsten bearbeiteten Datei immer noch einmal
>>> deren Zustände aus den Vortagen oder Vorwochen wieder sehen.
>>>
>>> Man kann das auch als primitives selbstgebaute Time Machine /
>>> Timeshift / VCS ansehen. Ich brauche es zirka einmal wöchentlich.
>> 
>> Das scheint mir fast aufwendiger, als auf bewährte Mechanismen zu
>> setzten, also z.B. rsync-basierende tools oder modernere wie borg oder
>> restic. Dann kann man auch nicht so leicht Sachen vergessen zu sichern.
>
> Na ja, Nachteil dieser speziellen Backup-Lösungen ist doch, dass man 
> diese dann auch immer benötigt, wenn man auf seinen eigenen Rechner 
> nicht mehr zugreifen kann.

Das verstehe ich nicht wirklich. IN 99% der Fälle braucht man ein
Backup, wenn man (=der User) sich versehentlich ein File oder ein
Direcory gelöscht oder sonstwie kaputtgemacht hat. In diesem Fall ist
"der Rechner" natürlich noch verfügbar, es haben nur 1 bis 1000+ Files
den falschen Inhalt oder existieren gar nicht mehr. Im restlichen 1% der
Fälle existiert der Rechner nicht mehr (entweder wegen Hardwareschaden
oder - häufiger - weil er ausgeschieden wurde und im nachhinein doch
noch jemand (ich!) draufkommt, dass er Daten von dem Server braucht).

Jede Backup-Software, die ich jemals verwendet habe, deckt beide Fälle
ab, der Aufwand für ein Restore kann aber deutlich unterschiedlich sein.

        hp

[toc] | [prev] | [next] | [standalone]

#131467

Am 16.06.23 um 17:34 schrieb Peter J. Holzer:
> On 2023-06-16 09:38, Matthias Gerds <m.gerds@posteo.de> wrote:
>> Am 16.06.23 um 01:38 schrieb Marcus Jodorf:
>>> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>>>
>>>> Datensicherungen sollen ja beispielweise gegen Hardware-Ausfälle
>>>> absichern. Aber bei mir ist das häufigste Problem, daß ich
>>>> selber eine Datei durch normale Bearbeitung verändert oder
>>>> versehentlich gelöscht habe und dann eine Version brauche,
>>>> die praktisch von gestern oder der vorigen Woche ist.
> 
> Nicht nur bei Dir. Meiner Erfahrung nach ist das bei weitem der
> häufigste Fall.
> 
> 
>>>> Dazu habe ich inzwischen die häufigsten Programme, welche ich
>>>> zur Dateibearbeitung verwende (Texteditoren, Textverarbeitungen,
>>>> Tabellenkalkulationen) so umgebaut, daß sie beim Öffnen oder
>>>> Schließen einer Datei noch eine Sicherungskopie, deren Name einen
>>>> aktuellen Zeitstempel enthält, in eine separaten Ordner speichern.
>>>> Das sammelt sich alles in einem großen Ordner, in dem ich dann
>>>> ab und zu ältere Kopien löschen muß.
>>>>
>>>> So kann ich bei den wichtigsten bearbeiteten Datei immer noch einmal
>>>> deren Zustände aus den Vortagen oder Vorwochen wieder sehen.
>>>>
>>>> Man kann das auch als primitives selbstgebaute Time Machine /
>>>> Timeshift / VCS ansehen. Ich brauche es zirka einmal wöchentlich.
>>>
>>> Das scheint mir fast aufwendiger, als auf bewährte Mechanismen zu
>>> setzten, also z.B. rsync-basierende tools oder modernere wie borg oder
>>> restic. Dann kann man auch nicht so leicht Sachen vergessen zu sichern.
>>
>> Na ja, Nachteil dieser speziellen Backup-Lösungen ist doch, dass man
>> diese dann auch immer benötigt, wenn man auf seinen eigenen Rechner
>> nicht mehr zugreifen kann.
> 
> Das verstehe ich nicht wirklich. IN 99% der Fälle braucht man ein
> Backup, wenn man (=der User) sich versehentlich ein File oder ein
> Direcory gelöscht oder sonstwie kaputtgemacht hat. In diesem Fall ist
> "der Rechner" natürlich noch verfügbar, es haben nur 1 bis 1000+ Files
> den falschen Inhalt oder existieren gar nicht mehr. Im restlichen 1% der
> Fälle existiert der Rechner nicht mehr (entweder wegen Hardwareschaden
> oder - häufiger - weil er ausgeschieden wurde und im nachhinein doch
> noch jemand (ich!) draufkommt, dass er Daten von dem Server braucht).
> 
> Jede Backup-Software, die ich jemals verwendet habe, deckt beide Fälle
> ab, der Aufwand für ein Restore kann aber deutlich unterschiedlich sein.

Bezog mich nur auf das eine Prozent der Situationen, in denen der 
Rechner nicht mehr verfügbar ist oder man die Daten andernorts 
sichten/sichern möchte. In diesem Fall braucht man dann ja auf jeden 
Fall die Backup-Software, die zumindest in fremden Umgebungen (z.B. 
Windows) nicht oder nicht in derselben Version  vorhanden ist. Deshalb 
erscheint mir ein einfaches GRSync doch ziemlich sinnvoll, obwohl z.B. 
Windows mit versteckten .Dateien und Sonderzeichen (z.B. '?') im 
Dateinamen auch nicht zurecht kommt. Zumindest hat GRSync kein 
spezielles Backup-Format, sondern kopiert die Daten einfach.

M:

[toc] | [prev] | [next] | [standalone]

#131521

Mahlzeit!


Matthias Gerds <m.gerds@posteo.de> wrote:

> Bezog mich nur auf das eine Prozent der Situationen, in denen der 
> Rechner nicht mehr verfügbar ist oder man die Daten andernorts 
> sichten/sichern möchte. In diesem Fall braucht man dann ja auf jeden 
> Fall die Backup-Software, die zumindest in fremden Umgebungen (z.B. 
> Windows) nicht oder nicht in derselben Version  vorhanden ist. Deshalb 
> erscheint mir ein einfaches GRSync doch ziemlich sinnvoll, obwohl z.B. 
> Windows mit versteckten .Dateien und Sonderzeichen (z.B. '?') im 
> Dateinamen auch nicht zurecht kommt. Zumindest hat GRSync kein 
> spezielles Backup-Format, sondern kopiert die Daten einfach.

Borg gibt's auch für Windows, das Problem mit ungültigen Dateinamen
hast Du unabhängig von der verwendeten Backuplösung.

Das ist wie üblich eine Abwägung:

 - Lesbarkeit unter Windows ist nur relevant, wenn man auch ein Windows
   hat ;-)

 - ein .tar.gz bekommst Du auf jedem Schuhkarton irgendwie ausgepackt

 - ein Borg-Repository dedupliziert und bleibt deutlich kleiner als
   ein Stapel .tar.gz-Fullbackups

 - Borg hat einen Integritätscheck eingebaut, bei .tar.gz musst Du
   Dich selbst drum kümmern (z.B. mit sha256sum).

 - Beim .tar.gz kannst Du mir par2 für Redundanz sorgen, bei Borg geht
   das eher nicht¹

Gruß
Christian


¹ Gibt's das/wäre das sinnvoll?  Man kann einen Overhead-Prozentsatz
  angeben, mit dem Borg automatisch Redundanz erzeugt, so dass
  einzelne Bitkipper aufgefangen werden können?  Die bloße
  Feststellung, dass ein Borg-Repository beschädigt ist
  (Integritätscheck), bringt einen ja im Falle des Falles nicht
  weiter.
-- 
....Christian.Garbs....................................https://www.cgarbs.de
A verter in aeris avi doctor.

[toc] | [prev] | [next] | [standalone]

#131497

Matthias Gerds <m.gerds@posteo.de> schrieb:

>> Das scheint mir fast aufwendiger, als auf bewährte Mechanismen zu
>> setzten, also z.B. rsync-basierende tools oder modernere wie borg
>> oder restic. Dann kann man auch nicht so leicht Sachen vergessen zu
>> sichern.
>
> Na ja, Nachteil dieser speziellen Backup-Lösungen ist doch, dass man
> diese dann auch immer benötigt, wenn man auf seinen eigenen Rechner
> nicht mehr zugreifen kann. Das kann mit GRSYNC o.ä. nicht
> passieren. Die Daten liegen schlicht als Kopie vor.
> Allerdings hat man als Linux-Benutzer erfahrungsgemäß noch das
> Problem, dass man seine Daten in fremder Umgebung (Windows  o.ä.)
> wegen eines meist inkompatiblen Dateissystems (ext4 vs. exFAT)
> schlecht einlesen kann. Und Sichern auf (ex)FAT geht auch nicht, da
> fehlen dann die ganzen versteckten Daten als auch Dateien mit
> inkompatiblen Zeichen im Dateinamen (z.B.'?' usw.). Alles schon
> durchprobiert.

Ein Linuxsystem zum Restore in Stellung zu bringen, sollte heutzutage
nicht wirklich ein Problem sein. Selbst wenn man es nicht griffbereit in
der Schublade hat, hat man sich doch ein geeignetes Rettungs-
bzw. Live-System doch binnen weniger Minuten auf USB-Stick oder externer
Platte schnell gebaut.
Da man restore ohnehin regelmäßig prüfen sollte, sollte das auch einfach
vorhanden sein.

> Und wenn der Schädling erst einmal im System ist, dann ist er auch
> ganz schnell auf Deinem Homeserver.

Allenfalls abgespeichert in deduplizierten Datenblöcken im borg
Repo. Tut dem Homeserver nichts.

> Klingt gut, muss ich mir mal ansehen. Bis dahin setze ich für
> persönliche Daten nach wie vor auf externe Platten (die eben nicht
> ständig erreichbar sind). Das ist zugegebenermaßen sehr unpraktisch
> und auch keine besonders elegante Lösung, weil die Fehlerquelle (ein
> Hoch auf das Vergessen) auch meist vor dem Computer sitzt. :-)

Sollte man daher auch möglichst automatisieren. Ich mach das z.B. über udev
Regeln. Sobald eine Platte mit „BACKUP“ im Namen angestöpselt wird, wird
das Backupverzeichnis vom Homeserver auf die Platte kopiert und danach
wieder unmounted. Als User braucht man nur anstöpseln und wenn die
Laufwerks-LED wieder ausgegangen ist, kann man einfach wieder
ausstöpseln und die Platte wieder wegpacken.

> Wahrscheinlich ist eine Mehrfachabsicherung mit verschiedenen Lösungen
> - u.a. wie von Dir beschrieben - noch die beste Herangehensweise.

Schadet nicht, Gürtel UND Hosenträger zu verwenden ;-)


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#131520

Am 16.06.23 um 11:38 schrieb Matthias Gerds:
> Allerdings hat man als Linux-Benutzer erfahrungsgemäß noch das Problem, 
> dass man seine Daten in fremder Umgebung (Windows  o.ä.) wegen eines 
> meist inkompatiblen Dateisystems (ext4 vs. exFAT) schlecht einlesen 
> kann. Und Sichern auf (ex)FAT geht auch nicht, da fehlen dann die ganzen 
> versteckten Daten als auch Dateien mit inkompatiblen Zeichen im 
> Dateinamen (z.B.'?' usw.). Alles schon durchprobiert.

Für diese Fälle gibt es raspberry pi.
So ein kompletter raspberry pi 400 kostet ca 100 €
und lässt sich an Fernseher oder Monitore mit HDMI anschließen.

>> Zusätzlich werden über hooks in apt auch noch jedesmal snapshots von
>> allen davon berührten Volumes (Abgleich installed files der Pakete mit
>> lokalen Pfaden/Volumes) gemacht, sobald ein Paket installiert oder
>> deinstalliert wird. Das heißt, sollte da mal was schiefgehen, reicht ein
>> rollback und die Packetinstallation/Upgrade hat nie stattgefunden.
>> (Für den selteneren Fall, daß ein Paketupdate Sachen geändert hat, die
>> nicht von der file list im Paket abgedeckt werden, hat man immer noch
>> die regulären Snapshots, die das ganze System abdecken).
> 
> Klingt gut, muss ich mir mal ansehen. Bis dahin setze ich für 
> persönliche Daten nach wie vor auf externe Platten (die eben nicht 
> ständig erreichbar sind). Das ist zugegebenermaßen sehr unpraktisch und 
> auch keine besonders elegante Lösung, weil die Fehlerquelle (ein Hoch 
> auf das Vergessen) auch meist vor dem Computer sitzt. :-)

Ein Problem bei der Datensicherung ist, dass die Dateien nicht mehr
zum neuen System passen.
Z.B. Dateinen mit iso-Sonterzeichen machen auf Konsole mit
utf8 Probleme.
Und wenn ich uralte Grafik System Dateien kopieren würde,
säße ich erst mal ( bis zur kompletten Neuinstallation )
vor dunklen Bildschirmen.
Alte .doc Dateien sind eventuell praktisch nicht mehr lesbar,
alte Quelldateien haben kein update..

Aus diesem Grunde rette ich nur geänderte Dateien wie z.B. /etc/fstab
( u.a. als Vorlage für tmpfs )

Ein Problem sind die softlinks.

> Den Rest (System) erledigt Timeshift.

Ich neige eher dazu,
gelegentlich selbst editierte Dateien in ein anderes Verzeichnis
auf dem gleichen computer zu kopieren.


>> Echtes Backup ist natürlich noch einmal unabhängig davon aber gerade
>> gegen die Fälle von Benutzerfehlern, Fehlern bei Updates usw. kann man
>> sich relativ gut und bequem mit solchen Mechanismen absichern.
>> Da reichen wie gesagt schon Sachen basierend auf
>> rsync/borg/restic/usw. für das Wesentliche.
>> Entscheidend ist dabei, daß es voll automatisiert und damit regelmäßig
>> und tatsächlich stattfindet.
> 
> Wahrscheinlich ist eine Mehrfachabsicherung mit verschiedenen Lösungen - 
> u.a. wie von Dir beschrieben - noch die beste Herangehensweise.

Ich hole höchsten einzelne Dateien zurück.
Die anderen Änderung kann ich nicht so ohne weiteres nachvollziehen.

Hermann
    rsync -a --delete und/oder eigene Programme in Python verwendend.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#131572

Am 18.06.23 um 12:01 schrieb Hermann Riemann:
> Am 16.06.23 um 11:38 schrieb Matthias Gerds:
>> Allerdings hat man als Linux-Benutzer erfahrungsgemäß noch das Problem,
>> dass man seine Daten in fremder Umgebung (Windows  o.ä.) wegen eines
>> meist inkompatiblen Dateisystems (ext4 vs. exFAT) schlecht einlesen
>> kann. Und Sichern auf (ex)FAT geht auch nicht, da fehlen dann die ganzen
>> versteckten Daten als auch Dateien mit inkompatiblen Zeichen im
>> Dateinamen (z.B.'?' usw.). Alles schon durchprobiert.
> 
> Für diese Fälle gibt es raspberry pi.
> So ein kompletter raspberry pi 400 kostet ca 100 €
> und lässt sich an Fernseher oder Monitore mit HDMI anschließen.

Was hat der Raspi damit zu tun? Nur, weil der ein Linux-kompatibles 
Dateisystem hat? Da könnte man ja auch jede beliebige Linux-Partition 
nehmen. Also externe Platten finde ich da schon sinnvoller. Man muss sie 
halt vorher umformatieren auf ext4 oder was auch immer.
Außerdem versieht der Raspi bei mir den Dienst als Internetzuspieler für 
die Uralt-Glotze.

>>> Zusätzlich werden über hooks in apt auch noch jedesmal snapshots von
>>> allen davon berührten Volumes (Abgleich installed files der Pakete mit
>>> lokalen Pfaden/Volumes) gemacht, sobald ein Paket installiert oder
>>> deinstalliert wird. Das heißt, sollte da mal was schiefgehen, reicht ein
>>> rollback und die Packetinstallation/Upgrade hat nie stattgefunden.
>>> (Für den selteneren Fall, daß ein Paketupdate Sachen geändert hat, die
>>> nicht von der file list im Paket abgedeckt werden, hat man immer noch
>>> die regulären Snapshots, die das ganze System abdecken).
>>
>> Klingt gut, muss ich mir mal ansehen. Bis dahin setze ich für
>> persönliche Daten nach wie vor auf externe Platten (die eben nicht
>> ständig erreichbar sind). Das ist zugegebenermaßen sehr unpraktisch und
>> auch keine besonders elegante Lösung, weil die Fehlerquelle (ein Hoch
>> auf das Vergessen) auch meist vor dem Computer sitzt. :-)
> 
> Ein Problem bei der Datensicherung ist, dass die Dateien nicht mehr
> zum neuen System passen.
> Z.B. Dateinen mit iso-Sonterzeichen machen auf Konsole mit
> utf8 Probleme.
> Und wenn ich uralte Grafik System Dateien kopieren würde,
> säße ich erst mal ( bis zur kompletten Neuinstallation )
> vor dunklen Bildschirmen.
> Alte .doc Dateien sind eventuell praktisch nicht mehr lesbar,
> alte Quelldateien haben kein update..
> 
> Aus diesem Grunde rette ich nur geänderte Dateien wie z.B. /etc/fstab
> ( u.a. als Vorlage für tmpfs )
> 
> Ein Problem sind die softlinks.
> 
>> Den Rest (System) erledigt Timeshift.
> 
> Ich neige eher dazu,
> gelegentlich selbst editierte Dateien in ein anderes Verzeichnis
> auf dem gleichen computer zu kopieren.

Das kann durchaus sinnvoll sein. Ich für meinen Teil habe 
sicherheitshalber zwei identische Arbeitssysteme (auf verschiedenen 
Partitionen), muss diese aber auch beide stets aktuell halten, damit es 
keinen Ärger gibt, weil beide dieselbe Home-Partition benutzen.

>>> Echtes Backup ist natürlich noch einmal unabhängig davon aber gerade
>>> gegen die Fälle von Benutzerfehlern, Fehlern bei Updates usw. kann man
>>> sich relativ gut und bequem mit solchen Mechanismen absichern.
>>> Da reichen wie gesagt schon Sachen basierend auf
>>> rsync/borg/restic/usw. für das Wesentliche.
>>> Entscheidend ist dabei, daß es voll automatisiert und damit regelmäßig
>>> und tatsächlich stattfindet.
>>
>> Wahrscheinlich ist eine Mehrfachabsicherung mit verschiedenen Lösungen -
>> u.a. wie von Dir beschrieben - noch die beste Herangehensweise.
> 
> Ich hole höchsten einzelne Dateien zurück.
> Die anderen Änderung kann ich nicht so ohne weiteres nachvollziehen.
> 
> Hermann
>      rsync -a --delete und/oder eigene Programme in Python verwendend.


So, so.

M:

[toc] | [prev] | [next] | [standalone]

#131463

Stefan Ram <ram@zedat.fu-berlin.de> wrote:

>   Wenn ich Dich richtig verstehe, empfiehlst Du mir automatische
>   inkrementelle Sicherungen. Darüber sollte ich sicher einmal
>   nachdenken. Danke für den Hinweis auf rsync, borg und Ähnliches!

Fuer "uups, versehentlich geloescht" helfen stuendliche Snapshots am
einfachsten. Das kann man via crontab automatisieren.


Fuer den Desasterfall kaputte Platte braucht es zusaetzliches Fullback auf
externen Datenmtraeger.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#131464

Ulli Horlacher schrieb:

> Fuer den Desasterfall kaputte Platte braucht es zusaetzliches Fullback auf
> externen Datenmtraeger.
> 
Mal so ganz leise gesagt, dafür benutze ich Acronis True Image.

Freundliche Grüße
Wolfgang
-- 

[toc] | [prev] | [next] | [standalone]

#131461

Am 15.06.23 um 22:07 schrieb Stefan Ram:
> Matthias Gerds <m.gerds@posteo.de> writes:
>> Gerade heute erst wieder gemerkt, wie wichtig ganz normale Backups sind.

Heute habe ich gemerkt das backups eventuell nichts taugen.

Ich wollte Tastatureingaben über SDL2 ausgeben.
Die alte Schnittstelle, die auch über google auffindbar ist,
ist SDL1 und funktioniert nicht mehr.

> ...
>> Aber im Grunde sollte man jeden Tag ein Backup machen.

Es gibt da für Heimanwender 2 Möglichkeiten ( + die Kombination):
Backup auf andere PCs ( oder raspi)
oder auf USB-Platte.

Also kopiere ich Inhalte, die ich behalten will,
auf einen PC, und mach von da aus Datensicherung auf USB.
z.B. Eine Woche auf Platte A die nächste auf Platte B.
Ein Testprogramm, welches den Inhalt kontrolliert,
( Schutz gegen Löschung durch gewisse Art von malware)
ist in der Erwägungsphase.

>    Datensicherungen sollen ja beispielweise gegen Hardware-Ausfälle
>    absichern. Aber bei mir ist das häufigste Problem, daß ich
>    selber eine Datei durch normale Bearbeitung verändert oder
>    versehentlich gelöscht habe und dann eine Version brauche,
>    die praktisch von gestern oder der vorigen Woche ist.

Gerade gelöscht kann schon eher vorkommen.

rm * ~ + statt rm *~ ist häufiger als rm -r $HOME
( Letzteres ist auch bei mir schon vorgekommen,
   hat mich aber seltsamerweise überhaupt nicht gestört. )

>    Dazu habe ich inzwischen die häufigsten Programme, welche ich
>    zur Dateibearbeitung verwende (Texteditoren, Textverarbeitungen,
>    Tabellenkalkulationen) so umgebaut, daß sie beim Öffnen oder
>    Schließen einer Datei noch eine Sicherungskopie, deren Name einen
>    aktuellen Zeitstempel enthält,

Emacs lässt immer so ein dateiname~
was bei grep hinderlich ist. Und dann gibt es noch
Dateien mit Namen #dateiname#, bei denen ich nicht weiss,
wie aktuell die ist.

( emacs und browser sind bei .svg Datien komisch.
   browser zeigen die Datei als plain Text,
   emacs als Bild.)

> in eine separaten Ordner speichern.
> Das sammelt sich alles in einem großen Ordner, in dem ich dann
> ab und zu ältere Kopien löschen muß.

Ich war es gewohnt Sicherungen nicht zu verwenden.

>    So kann ich bei den wichtigsten bearbeiteten Datei immer noch einmal
>    deren Zustände aus den Vortagen oder Vorwochen wieder sehen.

Die müsste ich dann mal aktualisieren,
  was in Arbeit ausarten würde.

>    Man kann das auch als primitives selbstgebaute Time Machine /
>    Timeshift / VCS ansehen. Ich brauche es zirka einmal wöchentlich.

Ich bin Reparaturen gewohnt.
Wenn jeder ca 20.Buchstabe nicht stimmt,
shift Taste manchmal klemmt ..
der Mauszeiger nicht an der Stelle ich,
an der ich gerade tippe..
( 2 32" Monitor + 4 K,
   wo dann der Mauszeiger im Textbereich
   nur ein kaum sichtbarer Strich ist.)

Hermann
    über dessen alte C-Programme
    sich der aktuelle C-compiler beschwert.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#131376

Am 14.06.23 um 17:52 schrieb Matthias Gerds:
> Hallo,
> 
> bei mir wird seit ? ein eingesteckter USB-Stick automatisch eingebunden, 
> WAS ICH NICHT WILL!
> 
> Wie abstellen? Ich arbeite mit KDE-Plasma unter LMDE (Linux Mint 
> Debian). In den KDE-Einstellungen ist das 'automatische Einhängen von 
> Wechselmedien' abgestellt. Aber nach dem manuellen Mounten eines Sticks 
> wird der nächste im KDE-Dateimanager (Dolphin) wieder automatisch 
> gemountet, sobald ich dort auf den
> Stick klicke. Warum steht der da überhaupt noch drin?
> Grrrrxl! History-Funktion von Dolphin? Oder liegt's an irgendwelchen 
> Geräte-Aktionen?

Wenn es nur dieser eine stick ist,
würde ich in /etc/fstab mal nachschauen.

Bei Dolphin würde ich eventuell
zum anschauen eine anderer Ordner wählen z.B. /home

Gibt es noch andere Verweise
  ( Konsole, Tab im browser) auf den stick?

[toc] | [prev] | [next] | [standalone]

#131379

Am 14.06.23 um 18:32 schrieb Hermann Riemann:
> Am 14.06.23 um 17:52 schrieb Matthias Gerds:
>> Hallo,
>>
>> bei mir wird seit ? ein eingesteckter USB-Stick automatisch eingebunden,
>> WAS ICH NICHT WILL!
>>
>> Wie abstellen? Ich arbeite mit KDE-Plasma unter LMDE (Linux Mint
>> Debian). In den KDE-Einstellungen ist das 'automatische Einhängen von
>> Wechselmedien' abgestellt. Aber nach dem manuellen Mounten eines Sticks
>> wird der nächste im KDE-Dateimanager (Dolphin) wieder automatisch
>> gemountet, sobald ich dort auf den
>> Stick klicke. Warum steht der da überhaupt noch drin?
>> Grrrrxl! History-Funktion von Dolphin? Oder liegt's an irgendwelchen
>> Geräte-Aktionen?
> 
> Wenn es nur dieser eine stick ist,
> würde ich in /etc/fstab mal nachschauen.

Nein, da steht der nicht drin. Da würde ja das ganze System nicht mehr 
hochfahren, wenn er den nicht findet beim booten. Habe ich gerade 
erlebt: Eine temporäre Partition (für /tmp oder so) eingetragen, und bei 
den Mount-Parametern statt ',' aus Versehen '.' geschrieben. Und schon 
fuhr der Rechner nicht mehr hoch. Also die /etc/fstab ist schon extrem 
sensibel beim booten.

> Bei Dolphin würde ich eventuell
> zum anschauen eine anderer Ordner wählen z.B. /home

??

> Gibt es noch andere Verweise
>    ( Konsole, Tab im browser) auf den stick?

Nicht dass ich wüsste. Aber scheinbar macht der KDE-Dateimanager 
(Dolphin) das obligatorisch, dass alle Geräte, die er findet, in der 
Seitenleiste aufgeführt werden. Konnte ich ihm jedenfalls bisher nicht 
abgewöhnen. Immerhin mountet er das Gerät das erst beim Draufklicken. 
Ist aber eigentlich nicht das Verhalten, das ich möchte. Jeder weiß 
doch, wie riskant USB-Sticks für ein System sein können.
Die sollten IMHO besser nicht automatisch eingebunden (gemountet) werden.


M:

[toc] | [prev] | [next] | [standalone]

#131428

Hallo,


Am 14.06.23 um 19:20 schrieb Matthias Gerds:
> Am 14.06.23 um 18:32 schrieb Hermann Riemann:
>> Am 14.06.23 um 17:52 schrieb Matthias Gerds:
>>> Hallo,
>>>
>>> bei mir wird seit ? ein eingesteckter USB-Stick automatisch eingebunden,
>>> WAS ICH NICHT WILL!
>>>
>>> Wie abstellen? Ich arbeite mit KDE-Plasma unter LMDE (Linux Mint
>>> Debian). In den KDE-Einstellungen ist das 'automatische Einhängen von
>>> Wechselmedien' abgestellt. Aber nach dem manuellen Mounten eines Sticks
>>> wird der nächste im KDE-Dateimanager (Dolphin) wieder automatisch
>>> gemountet, sobald ich dort auf den
>>> Stick klicke. Warum steht der da überhaupt noch drin?
>>> Grrrrxl! History-Funktion von Dolphin? Oder liegt's an irgendwelchen
>>> Geräte-Aktionen?
>>
>> Wenn es nur dieser eine stick ist,
>> würde ich in /etc/fstab mal nachschauen.
> 
> Nein, da steht der nicht drin. Da würde ja das ganze System nicht mehr 
> hochfahren, wenn er den nicht findet beim booten.

Nicht unbedingt, wenn er, bzw. das Dateisystem darauf zum korrekten 
Hochfahren des Systems gar nicht gebraucht wird.

Hängt außerdem natürlich von den Optionen, die Du in der fstab stehen 
hast. Z.B. mit noauto wird ein FS überhaupt nicht gemountet, bis Du das 
ausdrücklich per Kommando machst. Sollte also bei dem Stick in der fstab 
stehen. Mit nofail wird verhindert, dass der Systemstart verzögert wird, 
wenn z.B. ein NFS-Server nicht erreichbar ist.

> Habe ich gerade 
> erlebt: Eine temporäre Partition (für /tmp oder so) eingetragen, und bei 
> den Mount-Parametern statt ',' aus Versehen '.' geschrieben. Und schon 
> fuhr der Rechner nicht mehr hoch. Also die /etc/fstab ist schon extrem 
> sensibel beim booten.

Warum sollte eine temporäre Sonstwas-Partition für's Hochfahren relevant 
sein? Hauptsache, das Root-Dateisystem ist verfügbar.

Übrigens: nicht eine Partition wird eigentlich gemountet, sondern das 
darauf befindliche Dateisystem. Das siehst Du z.B. an verschlüsselten 
Dateisystemen: erst nach dem Unlock kann gemountet werden, dann aber 
nicht das Raw-Device sondern das Crypto-Device.


Gruß, Tom

[toc] | [prev] | [next] | [standalone]

#131431

Am 15.06.23 um 16:42 schrieb SimplyNews:
> Hallo,
> 
> 
> Am 14.06.23 um 19:20 schrieb Matthias Gerds:
>> Am 14.06.23 um 18:32 schrieb Hermann Riemann:
>>> Am 14.06.23 um 17:52 schrieb Matthias Gerds:
>>>> Hallo,
>>>>
>>>> bei mir wird seit ? ein eingesteckter USB-Stick automatisch eingebunden,
>>>> WAS ICH NICHT WILL!
>>>>
>>>> Wie abstellen? Ich arbeite mit KDE-Plasma unter LMDE (Linux Mint
>>>> Debian). In den KDE-Einstellungen ist das 'automatische Einhängen von
>>>> Wechselmedien' abgestellt. Aber nach dem manuellen Mounten eines Sticks
>>>> wird der nächste im KDE-Dateimanager (Dolphin) wieder automatisch
>>>> gemountet, sobald ich dort auf den
>>>> Stick klicke. Warum steht der da überhaupt noch drin?
>>>> Grrrrxl! History-Funktion von Dolphin? Oder liegt's an irgendwelchen
>>>> Geräte-Aktionen?
>>>
>>> Wenn es nur dieser eine stick ist,
>>> würde ich in /etc/fstab mal nachschauen.
>>
>> Nein, da steht der nicht drin. Da würde ja das ganze System nicht mehr
>> hochfahren, wenn er den nicht findet beim booten.
> 
> Nicht unbedingt, wenn er, bzw. das Dateisystem darauf zum korrekten
> Hochfahren des Systems gar nicht gebraucht wird.
> 
> Hängt außerdem natürlich von den Optionen, die Du in der fstab stehen
> hast. Z.B. mit noauto wird ein FS überhaupt nicht gemountet, bis Du das
> ausdrücklich per Kommando machst. Sollte also bei dem Stick in der fstab
> stehen. Mit nofail wird verhindert, dass der Systemstart verzögert wird,
> wenn z.B. ein NFS-Server nicht erreichbar ist.
> 
>> Habe ich gerade
>> erlebt: Eine temporäre Partition (für /tmp oder so) eingetragen, und bei
>> den Mount-Parametern statt ',' aus Versehen '.' geschrieben. Und schon
>> fuhr der Rechner nicht mehr hoch. Also die /etc/fstab ist schon extrem
>> sensibel beim booten.
> 
> Warum sollte eine temporäre Sonstwas-Partition für's Hochfahren relevant
> sein? Hauptsache, das Root-Dateisystem ist verfügbar.

/tmp
/var/log (ich hatte fälschlicherweise
noatime.nosuid statt noatime,nosuid als Parameter eingetragen)

sind relevant für's System.

/home/<Benutzer>/.cache

nicht unbedingt.

> Übrigens: nicht eine Partition wird eigentlich gemountet, sondern das
> darauf befindliche Dateisystem. Das siehst Du z.B. an verschlüsselten
> Dateisystemen: erst nach dem Unlock kann gemountet werden, dann aber
> nicht das Raw-Device sondern das Crypto-Device.

Das mag sein. Aber bisher habe ich hier nichts verschlüsselt, aber das 
kommt.

M:

[toc] | [prev] | [next] | [standalone]

#131438

On 2023-06-15 14:42, SimplyNews <Simply.News@gmx.de> wrote:
> Am 14.06.23 um 19:20 schrieb Matthias Gerds:
>> Nein, da steht der nicht drin. Da würde ja das ganze System nicht mehr 
>> hochfahren, wenn er den nicht findet beim booten.
>
> Nicht unbedingt, wenn er, bzw. das Dateisystem darauf zum korrekten 
> Hochfahren des Systems gar nicht gebraucht wird.

Wenn sie in /etc/fstab eingetragen sind (und nicht mit noauto o.ä.
ausgenommen sind), dann werden sie zum Hochfahren des Systems
gebraucht.


>> Habe ich gerade erlebt: Eine temporäre Partition (für /tmp oder so)
>> eingetragen, und bei den Mount-Parametern statt ',' aus Versehen '.'
>> geschrieben. Und schon fuhr der Rechner nicht mehr hoch. Also die
>> /etc/fstab ist schon extrem sensibel beim booten.
>
> Warum sollte eine temporäre Sonstwas-Partition für's Hochfahren relevant 
> sein?

/tmp zu mounten, wenn bereits Programme darauf Files abgelegt haben, ist
eine ganz schlechte Idee. Das sollte schon sehr früh im Boot-Prozess
gemountet werden.

> Hauptsache, das Root-Dateisystem ist verfügbar.

Am Root-Filesystem habe gerade mal /etc. Damit käme ich nicht weit.

        hp

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web