Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > ger.ct > #274396 > unrolled thread
| Started by | Hermann Riemann <nospan.gerct08@hermann-riemann.de> |
|---|---|
| First post | 2016-09-30 15:53 +0200 |
| Last post | 2016-10-01 12:30 +0200 |
| Articles | 20 on this page of 69 — 14 participants |
Back to article view | Back to ger.ct
SSD Überschreibgrenze? Hermann Riemann <nospan.gerct08@hermann-riemann.de> - 2016-09-30 15:53 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-09-30 18:06 +0200
Re: SSD Überschreibgrenze? Shinji Ikari <shinji@gmx.net> - 2016-09-30 20:49 +0200
Re: SSD Überschreibgrenze? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-30 19:36 +0000
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-09-30 21:43 +0200
Re: SSD Überschreibgrenze? Hermann Riemann <nospan.gerct08@hermann-riemann.de> - 2016-10-01 10:18 +0200
Re: SSD Überschreibgrenze? Martin Gerdes <martin.gerdes@gmx.de> - 2016-10-01 00:33 +0200
Re: SSD Überschreibgrenze? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-10-01 07:48 +0000
Re: SSD Überschreibgrenze? Martin Gerdes <martin.gerdes@gmx.de> - 2016-10-01 15:28 +0200
Re: SSD Überschreibgrenze? Shinji Ikari <shinji@gmx.net> - 2016-10-01 11:27 +0200
Re: SSD Überschreibgrenze? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-10-02 18:56 +0000
Re: SSD Überschreibgrenze? Martin Gerdes <martin.gerdes@gmx.de> - 2016-10-01 00:33 +0200
Re: SSD Überschreibgrenze? Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-10-01 00:57 +0000
Re Wirkungsgrad (was: SSD Überschreibgrenze?) Hermann Riemann <nospan.gerct08@hermann-riemann.de> - 2016-10-01 10:30 +0200
Re: SSD Überschreibgrenze? Shinji Ikari <shinji@gmx.net> - 2016-10-01 11:36 +0200
Re: SSD Überschreibgrenze? Hanno Foest <hurga-news2@tigress.com> - 2016-10-01 15:16 +0200
Re: SSD Überschreibgrenze? spamfalle2@arcor.de (Marc Stibane) - 2016-10-02 12:30 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-02 12:43 +0200
Re: SSD Überschreibgrenze? spamfalle2@arcor.de (Marc Stibane) - 2016-10-02 13:56 +0200
Re: SSD Überschreibgrenze? spamfalle2@arcor.de (Marc Stibane) - 2016-10-01 09:54 +0200
Re: SSD Überschreibgrenze? Shinji Ikari <shinji@gmx.net> - 2016-10-01 11:37 +0200
Re: SSD Überschreibgrenze? Martin Gerdes <martin.gerdes@gmx.de> - 2016-10-01 15:28 +0200
Re: SSD Überschreibgrenze? spamfalle2@arcor.de (Marc Stibane) - 2016-10-02 12:30 +0200
Re: SSD Überschreibgrenze? Martin Gerdes <martin.gerdes@gmx.de> - 2016-10-02 17:05 +0200
Re: SSD Überschreibgrenze? Holger Marzen <holger@marzen.de> - 2016-10-02 15:13 +0000
Re: SSD Überschreibgrenze? Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-09-30 19:59 +0000
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-09-30 22:05 +0200
Re: SSD Überschreibgrenze? Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-09-30 20:13 +0000
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-09-30 22:16 +0200
Re: SSD Überschreibgrenze? Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-09-30 20:29 +0000
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-09-30 22:38 +0200
Re: SSD Überschreibgrenze? Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-09-30 20:47 +0000
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-09-30 22:51 +0200
Re: SSD Überschreibgrenze? Hanno Foest <hurga-news2@tigress.com> - 2016-10-01 04:56 +0200
Re: SSD Überschreibgrenze? spamfalle2@arcor.de (Marc Stibane) - 2016-10-01 09:54 +0200
Re: SSD Überschreibgrenze? Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-10-01 08:27 +0000
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-01 11:19 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-01 11:15 +0200
Re: SSD Überschreibgrenze? Walter Schmid <paulwalterschmid@vtxmail.ch> - 2016-10-01 12:07 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-01 12:12 +0200
Re: SSD Überschreibgrenze? Günter Frenz <usenet-01@guefz.de> - 2016-10-01 12:19 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-01 12:29 +0200
Re: SSD Überschreibgrenze? Günter Frenz <usenet-01@guefz.de> - 2016-10-01 12:43 +0200
Re Backup (was: SSD Überschreibgrenze?) Hermann Riemann <nospan.gerct08@hermann-riemann.de> - 2016-10-03 07:31 +0200
Re: SSD Überschreibgrenze? spamfalle2@arcor.de (Marc Stibane) - 2016-10-02 12:30 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-02 12:40 +0200
Re: SSD Überschreibgrenze? Frank Möller <butterspiegeleiauftoast42@spl.at> - 2016-10-02 12:57 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-02 14:04 +0200
Re: SSD Überschreibgrenze? Frank Möller <butterspiegeleiauftoast42@spl.at> - 2016-10-02 14:29 +0200
Re: SSD Überschreibgrenze? Walter Schmid <paulwalterschmid@vtxmail.ch> - 2016-10-01 12:36 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-01 13:42 +0200
Re: SSD Überschreibgrenze? Walter Schmid <paulwalterschmid@vtxmail.ch> - 2016-10-03 08:35 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-03 08:52 +0200
Re: SSD Überschreibgrenze? Günter Frenz <usenet-01@guefz.de> - 2016-10-03 10:38 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-03 10:42 +0200
Re: SSD Überschreibgrenze? Günter Frenz <usenet-01@guefz.de> - 2016-10-03 11:00 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-03 11:07 +0200
Re: SSD Überschreibgrenze? Michael Bode <m.g.bode@web.de> - 2016-10-03 11:30 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-03 11:34 +0200
Re: SSD Überschreibgrenze? Michael Bode <m.g.bode@web.de> - 2016-10-03 13:50 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-03 14:04 +0200
Re: SSD Überschreibgrenze? Günter Frenz <usenet-01@guefz.de> - 2016-10-03 11:32 +0200
Re: (Linux) Dateisystem (was: SSD Überschreibgrenze?) Hermann Riemann <nospan.gerct08@hermann-riemann.de> - 2016-10-03 11:46 +0200
Re: (Linux) Dateisystem Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-03 11:59 +0200
Re: (Linux) Dateisystem Christian Garbs <mitch@cgarbs.de> - 2016-10-09 15:30 +0200
Re: SSD Überschreibgrenze? Walter Schmid <paulwalterschmid@vtxmail.ch> - 2016-10-03 11:06 +0200
Re: SSD Überschreibgrenze? Frank Möller <butterspiegeleiauftoast42@spl.at> - 2016-10-01 11:49 +0200
Re: SSD Überschreibgrenze? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-10-01 12:09 +0200
Re: SSD Überschreibgrenze? Frank Möller <butterspiegeleiauftoast42@spl.at> - 2016-10-01 12:30 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Günter Frenz <usenet-01@guefz.de> |
|---|---|
| Date | 2016-10-01 12:19 +0200 |
| Message-ID | <20161001121924.38ed0f2e@corinnis.midgard> |
| In reply to | #274554 |
Am Sat, 1 Oct 2016 12:12:44 +0200 schrieb Gerrit Heitsch: > On 10/01/2016 12:07 PM, Walter Schmid wrote: > > Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: > >> On 10/01/2016 09:54 AM, Marc Stibane wrote: > >>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: > >>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: > >>> > >>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf > >>>>> deiner HD/SSD liegt genug Zeug rum das bei der Installation > >>>>> geschrieben aber seitdem nur noch gelesen wird. > >>>> Solange es gelesen wird, weiß der Controller ja Bescheid. > >>>> Präventiv lesen wird er nichts. Ist auch völlig unnötig: Wer > >>>> regelmäßig Komplettbackups macht, bei dem wird alles mal > >>>> angefaßt. > >>> > >>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit > >>> dem letzten Backup geschrieben wurde. Und nur diese neuen Sachen > >>> werden in das nächste Backup geschrieben. Vollbackups macht > >>> TimeMachine nur auf neue Backup-Festplatten. > >> > >> Gleiches gilt für Backups mit 'rsync'. Warum sollte man Vollbackups > >> machen? Dauert doch viel zu lange. > > > > > > Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe > > ich nie Stress - aber beim Restore habe ich IMMER Stresss. > > Warum sollte der Restore eines rsync-Backups langsam sein? Ich baue > mir mit rsync sogar versionierte Backups a la Timemaschine. > '--link-dest=' machts möglich. Ich nutze rsnapshot als Frontend für rsync. Macht genau das was du da beschrieben hast. Ich habe zur Zeit 10 Versionen Backup auf jeder Backup-Platte, was nur etwa doppelt so viel Platz braucht wie das erste Vollbackup. Diese Quote hängt natürlich sehr stark vom Nutzungsverhalten ab. Günter
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-01 12:29 +0200 |
| Message-ID | <nso0nr$r2e$1@news.bawue.net> |
| In reply to | #274556 |
On 10/01/2016 12:19 PM, Günter Frenz wrote: > Am Sat, 1 Oct 2016 12:12:44 +0200 schrieb Gerrit Heitsch: > >> On 10/01/2016 12:07 PM, Walter Schmid wrote: >>> Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: >>>> On 10/01/2016 09:54 AM, Marc Stibane wrote: >>>>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: >>>>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: >>>>> >>>>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf >>>>>>> deiner HD/SSD liegt genug Zeug rum das bei der Installation >>>>>>> geschrieben aber seitdem nur noch gelesen wird. >>>>>> Solange es gelesen wird, weiß der Controller ja Bescheid. >>>>>> Präventiv lesen wird er nichts. Ist auch völlig unnötig: Wer >>>>>> regelmäßig Komplettbackups macht, bei dem wird alles mal >>>>>> angefaßt. >>>>> >>>>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit >>>>> dem letzten Backup geschrieben wurde. Und nur diese neuen Sachen >>>>> werden in das nächste Backup geschrieben. Vollbackups macht >>>>> TimeMachine nur auf neue Backup-Festplatten. >>>> >>>> Gleiches gilt für Backups mit 'rsync'. Warum sollte man Vollbackups >>>> machen? Dauert doch viel zu lange. >>> >>> >>> Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe >>> ich nie Stress - aber beim Restore habe ich IMMER Stresss. >> >> Warum sollte der Restore eines rsync-Backups langsam sein? Ich baue >> mir mit rsync sogar versionierte Backups a la Timemaschine. >> '--link-dest=' machts möglich. > > Ich nutze rsnapshot als Frontend für rsync. Macht genau das was du da > beschrieben hast. Ich habe zur Zeit 10 Versionen Backup auf jeder > Backup-Platte, was nur etwa doppelt so viel Platz braucht wie das erste > Vollbackup. Diese Quote hängt natürlich sehr stark vom > Nutzungsverhalten ab. Mein selbstgestricktes System erzeugt die Backups in Direktories die das aktuelle Datum im passenden Format als Namen tragen, erzeugt mit: date "+%F_%H-%M-%S" So ist der Kram auch von Hand schnell gefunden. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Günter Frenz <usenet-01@guefz.de> |
|---|---|
| Date | 2016-10-01 12:43 +0200 |
| Message-ID | <20161001124318.094fd970@corinnis.midgard> |
| In reply to | #274558 |
Am Sat, 1 Oct 2016 12:29:19 +0200 schrieb Gerrit Heitsch: > On 10/01/2016 12:19 PM, Günter Frenz wrote: > > Am Sat, 1 Oct 2016 12:12:44 +0200 schrieb Gerrit Heitsch: > > > >> On 10/01/2016 12:07 PM, Walter Schmid wrote: > >>> Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: > >>>> On 10/01/2016 09:54 AM, Marc Stibane wrote: > >>>>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: > >>>>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: > >>>>> > >>>>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf > >>>>>>> deiner HD/SSD liegt genug Zeug rum das bei der Installation > >>>>>>> geschrieben aber seitdem nur noch gelesen wird. > >>>>>> Solange es gelesen wird, weiß der Controller ja Bescheid. > >>>>>> Präventiv lesen wird er nichts. Ist auch völlig unnötig: Wer > >>>>>> regelmäßig Komplettbackups macht, bei dem wird alles mal > >>>>>> angefaßt. > >>>>> > >>>>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit > >>>>> dem letzten Backup geschrieben wurde. Und nur diese neuen Sachen > >>>>> werden in das nächste Backup geschrieben. Vollbackups macht > >>>>> TimeMachine nur auf neue Backup-Festplatten. > >>>> > >>>> Gleiches gilt für Backups mit 'rsync'. Warum sollte man > >>>> Vollbackups machen? Dauert doch viel zu lange. > >>> > >>> > >>> Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe > >>> ich nie Stress - aber beim Restore habe ich IMMER Stresss. > >> > >> Warum sollte der Restore eines rsync-Backups langsam sein? Ich baue > >> mir mit rsync sogar versionierte Backups a la Timemaschine. > >> '--link-dest=' machts möglich. > > > > Ich nutze rsnapshot als Frontend für rsync. Macht genau das was du > > da beschrieben hast. Ich habe zur Zeit 10 Versionen Backup auf jeder > > Backup-Platte, was nur etwa doppelt so viel Platz braucht wie das > > erste Vollbackup. Diese Quote hängt natürlich sehr stark vom > > Nutzungsverhalten ab. > > Mein selbstgestricktes System erzeugt die Backups in Direktories die > das aktuelle Datum im passenden Format als Namen tragen, erzeugt mit: > > date "+%F_%H-%M-%S" > > So ist der Kram auch von Hand schnell gefunden. In den meisten Fällen braucht man ja nur die letzte Version aus dem Backup, da tut es auch die einfache Nummerierung der Versionen von 0 bis 9. Wenn ich etwas weiter zurück liegendes brauche, muss ich eh die in Frage kommenden Versionen einzeln ansehen, da ich mir nicht exakt merke, wann ich was geändert oder hinzugefügt habe. Ich weiß dann nur so grob, dass ich die Version von vor 1 oder 2 Wochen brauche. Ansonsten behauptet die SSD im meinem Desktop, dass sie seit Anfang des Jahres ca. 71000 32MiB-Blöcke geschrieben hat. Da habe ich jedenfalls noch ein wenig Luft nach oben, obwohl ich ein Debian Sid benutze und jeden Tag die Updates einspiele. Günter
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospan.gerct08@hermann-riemann.de> |
|---|---|
| Date | 2016-10-03 07:31 +0200 |
| Subject | Re Backup (was: SSD Überschreibgrenze?) |
| Message-ID | <e5e8p3Fq2drU1@mid.individual.net> |
| In reply to | #274562 |
Am 01.10.2016 um 12:43 schrieb Günter Frenz:
>> Mein selbstgestricktes System erzeugt die Backups in Direktories die
>> das aktuelle Datum im passenden Format als Namen tragen, erzeugt mit:
>> date "+%F_%H-%M-%S"
>> So ist der Kram auch von Hand schnell gefunden.
> In den meisten Fällen braucht man ja nur die letzte Version aus dem
> Backup, da tut es auch die einfache Nummerierung der Versionen von 0
> bis 9.
Für die Datensicherung verwende ich Ordner auf Festplatte
und USB-Platten.
Derzeit verwende ich noch eine Folge von rsync -a Anweisungen
Bei selbst editierte Dateien brauche ich eine Zwischenstufe.
Das erreiche ich, indem ich nach der rsync -a Datensicherung
nochmal ein rsync -a eigene_Dateien irgendwas_sav/eigene_Dateien
wobei letzteres auf der Festplatte des Rechners liegt.
Damit habe ich schnellen Zugriff und einen Level bei der Sicherung.
> Wenn ich etwas weiter zurück liegendes brauche, muss ich eh die
> in Frage kommenden Versionen einzeln ansehen, da ich mir nicht exakt
> merke, wann ich was geändert oder hinzugefügt habe. Ich weiß dann nur
> so grob, dass ich die Version von vor 1 oder 2 Wochen brauche.
Wenn ich was weit zurückliegendes brauche,
müsste ich meine alten Platten reaktivieren
und mich dann mit ISO-utf-Probleme herumschlagen.
Hermann
der bei rsync -a eine Option vermisst,
welche auf dem kopierten Dateien und Ordner löschen lässt,
die im Original nicht mehr vorhanden sind.
--
www.Hermann-Riemann.de
[toc] | [prev] | [next] | [standalone]
| From | spamfalle2@arcor.de (Marc Stibane) |
|---|---|
| Date | 2016-10-02 12:30 +0200 |
| Message-ID | <1muhqru.1tt076p1s9dcprN@marc.my-fqdn.de> |
| In reply to | #274558 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: > Mein selbstgestricktes System erzeugt die Backups in Direktories die das > aktuelle Datum im passenden Format als Namen tragen, erzeugt mit: > date "+%F_%H-%M-%S" > > So ist der Kram auch von Hand schnell gefunden. Im Prinzip macht Apple ja mit TM genau dasselbe. Man kann die Backup- Disk(s) außer per GUI auch per Hand inspizieren und findet dort die Snapshots mit Datum im Namen. Der einzige Unterschied ist das GUI. Mit einem Klick einschalten, und mit einem Menüaufruf (Time Machine öffnen) kann auch ein Non-Nerd Backups machen und wiederherstellen. rsync --link-dest= bekommt der aber nicht hin. -- In a world without walls and fences, who needs windows and gates?
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-02 12:40 +0200 |
| Message-ID | <nsqlok$t4n$1@news.bawue.net> |
| In reply to | #274716 |
On 10/02/2016 12:30 PM, Marc Stibane wrote: > rsync --link-dest= bekommt der aber nicht hin. Ich auch nicht auswendig. Ich hab das einmal aus der man-page gelernt, ein Script damit gestrickt und seitdem funktioniert es. Brauche ich die Funktion woanders schaue ich mir das Script an und kopiere mir die Teile die ich brauche. Das ist eines der Probleme bei einem Unix... Einmal sauber implementiert funktioniert der Kram einfach. Klemmt es doch mal ist das Jahre später und man hat wieder vergessen wie es geht. Also giesse ich sowas in Scripte oder schreibe mir kleine How-To-Files. In denen erkläre ich mir selber warum was wie gemacht wurde. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Frank Möller <butterspiegeleiauftoast42@spl.at> |
|---|---|
| Date | 2016-10-02 12:57 +0200 |
| Message-ID | <021016.125725.483#22@m-id.net.gr.vu> |
| In reply to | #274722 |
Gerrit Heitsch schrieb: > On 10/02/2016 12:30 PM, Marc Stibane wrote: >> rsync --link-dest= bekommt der aber nicht hin. > Ich auch nicht auswendig. Ich hab das einmal aus der man-page gelernt, > ein Script damit gestrickt und seitdem funktioniert es. Brauche ich die > Funktion woanders schaue ich mir das Script an und kopiere mir die Teile > die ich brauche. > Das ist eines der Probleme bei einem Unix... Einmal sauber implementiert > funktioniert der Kram einfach. Das kann man mit Windows auch haben. Ich nehme halt nicht rsync, sondern je nach konkretem Fall Robocopy oder <http://schinagl.priv.at/nt/ln/ln.html> > Klemmt es doch mal ist das Jahre später > und man hat wieder vergessen wie es geht. Also giesse ich sowas in > Scripte oder schreibe mir kleine How-To-Files. In denen erkläre ich mir > selber warum was wie gemacht wurde. Jep, und geht unter Win auch. --
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-02 14:04 +0200 |
| Message-ID | <nsqql1$vfd$1@news.bawue.net> |
| In reply to | #274738 |
On 10/02/2016 12:57 PM, Frank Möller wrote: > Gerrit Heitsch schrieb: >> On 10/02/2016 12:30 PM, Marc Stibane wrote: > >>> rsync --link-dest= bekommt der aber nicht hin. > >> Ich auch nicht auswendig. Ich hab das einmal aus der man-page gelernt, >> ein Script damit gestrickt und seitdem funktioniert es. Brauche ich die >> Funktion woanders schaue ich mir das Script an und kopiere mir die Teile >> die ich brauche. > >> Das ist eines der Probleme bei einem Unix... Einmal sauber implementiert >> funktioniert der Kram einfach. > > Das kann man mit Windows auch haben. Ich nehme halt nicht rsync, sondern je > nach konkretem Fall Robocopy oder <http://schinagl.priv.at/nt/ln/ln.html> ln wurde von Unix kopiert. :) rsync funktioniert auch zwischen 2 Rechnern übers Netz, getunnelt durch ssh. > >> Klemmt es doch mal ist das Jahre später >> und man hat wieder vergessen wie es geht. Also giesse ich sowas in >> Scripte oder schreibe mir kleine How-To-Files. In denen erkläre ich mir >> selber warum was wie gemacht wurde. > > Jep, und geht unter Win auch. Nur das Einbauen von Kommentaren in Config-Files geht unter Unix viel einfacher weil die dort Text sind. Bei Windows gibts die Registry, da kann man nicht einfach mal kurz ein Setting kommentieren oder, für Testzwecke, auskommentieren. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Frank Möller <butterspiegeleiauftoast42@spl.at> |
|---|---|
| Date | 2016-10-02 14:29 +0200 |
| Message-ID | <021016.142924.443#47@m-id.net.gr.vu> |
| In reply to | #274764 |
Gerrit Heitsch schrieb: > On 10/02/2016 12:57 PM, Frank Möller wrote: >> Gerrit Heitsch schrieb: >>> On 10/02/2016 12:30 PM, Marc Stibane wrote: >>>> rsync --link-dest= bekommt der aber nicht hin. >>> Ich auch nicht auswendig. Ich hab das einmal aus der man-page gelernt, >>> ein Script damit gestrickt und seitdem funktioniert es. Brauche ich die >>> Funktion woanders schaue ich mir das Script an und kopiere mir die Teile >>> die ich brauche. >>> Das ist eines der Probleme bei einem Unix... Einmal sauber implementiert >>> funktioniert der Kram einfach. >> Das kann man mit Windows auch haben. Ich nehme halt nicht rsync, sondern je >> nach konkretem Fall Robocopy oder <http://schinagl.priv.at/nt/ln/ln.html> > ln wurde von Unix kopiert. :) Es funktioniert trotzdem. ;-) > rsync funktioniert auch zwischen 2 Rechnern übers Netz, getunnelt durch ssh. Prima. Ob das unter Win geht, weiß ich nicht. Wenn nicht, macht's mir dennoch nix aus, weil ich das nicht brauche. >>> Klemmt es doch mal ist das Jahre später >>> und man hat wieder vergessen wie es geht. Also giesse ich sowas in >>> Scripte oder schreibe mir kleine How-To-Files. In denen erkläre ich mir >>> selber warum was wie gemacht wurde. >> Jep, und geht unter Win auch. > Nur das Einbauen von Kommentaren in Config-Files geht unter Unix viel > einfacher weil die dort Text sind. Bei Windows gibts die Registry, da > kann man nicht einfach mal kurz ein Setting kommentieren oder, für > Testzwecke, auskommentieren. Der Mann von Welt erledigt Registry-Eingriffe unter Win ja auch per Batch/cmd-file oder .reg-Datei, und da das ebenfalls ganz normale Textdateien sind, ist das null prolemo. Ansonsten gibt's z. B. auch noch AutoHotkey, mit dem dann zusätzlich auch noch makrogesteuerte GUI-Aktionen möglich sind. --
[toc] | [prev] | [next] | [standalone]
| From | Walter Schmid <paulwalterschmid@vtxmail.ch> |
|---|---|
| Date | 2016-10-01 12:36 +0200 |
| Message-ID | <nso3iv$esr$1@dont-email.me> |
| In reply to | #274554 |
Am 01.10.2016 um 12:12 schrieb Gerrit Heitsch: > On 10/01/2016 12:07 PM, Walter Schmid wrote: >> Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: >>> On 10/01/2016 09:54 AM, Marc Stibane wrote: >>>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: >>>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: >>>> >>>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf deiner >>>>>> HD/SSD liegt genug Zeug rum das bei der Installation geschrieben aber >>>>>> seitdem nur noch gelesen wird. >>>>> Solange es gelesen wird, weiß der Controller ja Bescheid. Präventiv lesen >>>>> wird er nichts. Ist auch völlig unnötig: Wer regelmäßig Komplettbackups >>>>> macht, bei dem wird alles mal angefaßt. >>>> >>>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit dem >>>> letzten Backup geschrieben wurde. Und nur diese neuen Sachen werden in >>>> das nächste Backup geschrieben. Vollbackups macht TimeMachine nur auf >>>> neue Backup-Festplatten. >>> >>> Gleiches gilt für Backups mit 'rsync'. Warum sollte man Vollbackups >>> machen? Dauert doch viel zu lange. >> >> >> Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe >> ich nie Stress - aber beim Restore habe ich IMMER Stresss. > > Warum sollte der Restore eines rsync-Backups langsam sein? Das Problem beim Restore ist das finden des richtigen Backups und der richtigen Platte. Beim Vollbackup ist das sehr einfach. Gruss Walter
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-01 13:42 +0200 |
| Message-ID | <nso51q$slc$1@news.bawue.net> |
| In reply to | #274560 |
On 10/01/2016 12:36 PM, Walter Schmid wrote: > Am 01.10.2016 um 12:12 schrieb Gerrit Heitsch: >> On 10/01/2016 12:07 PM, Walter Schmid wrote: >>> Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: >>>> On 10/01/2016 09:54 AM, Marc Stibane wrote: >>>>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: >>>>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: >>>>> >>>>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf deiner >>>>>>> HD/SSD liegt genug Zeug rum das bei der Installation geschrieben aber >>>>>>> seitdem nur noch gelesen wird. >>>>>> Solange es gelesen wird, weiß der Controller ja Bescheid. Präventiv lesen >>>>>> wird er nichts. Ist auch völlig unnötig: Wer regelmäßig Komplettbackups >>>>>> macht, bei dem wird alles mal angefaßt. >>>>> >>>>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit dem >>>>> letzten Backup geschrieben wurde. Und nur diese neuen Sachen werden in >>>>> das nächste Backup geschrieben. Vollbackups macht TimeMachine nur auf >>>>> neue Backup-Festplatten. >>>> >>>> Gleiches gilt für Backups mit 'rsync'. Warum sollte man Vollbackups >>>> machen? Dauert doch viel zu lange. >>> >>> >>> Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe >>> ich nie Stress - aber beim Restore habe ich IMMER Stresss. >> >> Warum sollte der Restore eines rsync-Backups langsam sein? > > Das Problem beim Restore ist das finden des richtigen Backups und > der richtigen Platte. Beim Vollbackup ist das sehr einfach. Beim rsync-Backup auch, ist schliesslich auch ein Vollbackup, nur eben beim Backup schneller da nur kopiert wird was sich seit dem letzten Backup geändert hatte. Falls du mehr als ein Medium hast musst du auch beim Vollbackup das Medium mit dem aktuellsten Backup finden. Schenkt sich also nichts, rsync ist nur schneller. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Walter Schmid <paulwalterschmid@vtxmail.ch> |
|---|---|
| Date | 2016-10-03 08:35 +0200 |
| Message-ID | <nssu72$otb$1@dont-email.me> |
| In reply to | #274571 |
Am 01.10.2016 um 13:42 schrieb Gerrit Heitsch: > On 10/01/2016 12:36 PM, Walter Schmid wrote: >> Am 01.10.2016 um 12:12 schrieb Gerrit Heitsch: >>> On 10/01/2016 12:07 PM, Walter Schmid wrote: >>>> Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: >>>>> On 10/01/2016 09:54 AM, Marc Stibane wrote: >>>>>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: >>>>>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: >>>>>> >>>>>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf deiner >>>>>>>> HD/SSD liegt genug Zeug rum das bei der Installation geschrieben aber >>>>>>>> seitdem nur noch gelesen wird. >>>>>>> Solange es gelesen wird, weiß der Controller ja Bescheid. Präventiv lesen >>>>>>> wird er nichts. Ist auch völlig unnötig: Wer regelmäßig Komplettbackups >>>>>>> macht, bei dem wird alles mal angefaßt. >>>>>> >>>>>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit dem >>>>>> letzten Backup geschrieben wurde. Und nur diese neuen Sachen werden in >>>>>> das nächste Backup geschrieben. Vollbackups macht TimeMachine nur auf >>>>>> neue Backup-Festplatten. >>>>> >>>>> Gleiches gilt für Backups mit 'rsync'. Warum sollte man Vollbackups >>>>> machen? Dauert doch viel zu lange. >>>> >>>> >>>> Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe >>>> ich nie Stress - aber beim Restore habe ich IMMER Stresss. >>> >>> Warum sollte der Restore eines rsync-Backups langsam sein? >> >> Das Problem beim Restore ist das finden des richtigen Backups und >> der richtigen Platte. Beim Vollbackup ist das sehr einfach. > > Beim rsync-Backup auch, ist schliesslich auch ein Vollbackup, nur eben > beim Backup schneller da nur kopiert wird was sich seit dem letzten > Backup geändert hatte. Und Du bist ganz sicher, dass das System immer weiss, welche Dateien verändert, erstellt oder gelöscht wurden? Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener Erfahrung, dass auch Linux Daten verliert. Gruss Walter
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-03 08:52 +0200 |
| Message-ID | <nsssns$tpm$1@news.bawue.net> |
| In reply to | #274912 |
On 10/03/2016 08:35 AM, Walter Schmid wrote: > Am 01.10.2016 um 13:42 schrieb Gerrit Heitsch: >> On 10/01/2016 12:36 PM, Walter Schmid wrote: >>> Am 01.10.2016 um 12:12 schrieb Gerrit Heitsch: >>>> On 10/01/2016 12:07 PM, Walter Schmid wrote: >>>>> Am 01.10.2016 um 11:15 schrieb Gerrit Heitsch: >>>>>> On 10/01/2016 09:54 AM, Marc Stibane wrote: >>>>>>> Bernd Lauert <m8r-9vv4fj@mailinator.com> wrote: >>>>>>>> On Fri, 30 Sep 2016 22:38:27 +0200, Gerrit Heitsch wrote: >>>>>>> >>>>>>>>> Bei den heutigen Strukturen ist das nicht anders machbar. Auf deiner >>>>>>>>> HD/SSD liegt genug Zeug rum das bei der Installation geschrieben aber >>>>>>>>> seitdem nur noch gelesen wird. >>>>>>>> Solange es gelesen wird, weiß der Controller ja Bescheid. Präventiv lesen >>>>>>>> wird er nichts. Ist auch völlig unnötig: Wer regelmäßig Komplettbackups >>>>>>>> macht, bei dem wird alles mal angefaßt. >>>>>>> >>>>>>> MacOS: Es existiert ein Systemdienst der mitloggt was alles seit dem >>>>>>> letzten Backup geschrieben wurde. Und nur diese neuen Sachen werden in >>>>>>> das nächste Backup geschrieben. Vollbackups macht TimeMachine nur auf >>>>>>> neue Backup-Festplatten. >>>>>> >>>>>> Gleiches gilt für Backups mit 'rsync'. Warum sollte man Vollbackups >>>>>> machen? Dauert doch viel zu lange. >>>>> >>>>> >>>>> Dafür geht Vollbackup-Restore dann schneller. Beim Backuppen habe >>>>> ich nie Stress - aber beim Restore habe ich IMMER Stresss. >>>> >>>> Warum sollte der Restore eines rsync-Backups langsam sein? >>> >>> Das Problem beim Restore ist das finden des richtigen Backups und >>> der richtigen Platte. Beim Vollbackup ist das sehr einfach. >> >> Beim rsync-Backup auch, ist schliesslich auch ein Vollbackup, nur eben >> beim Backup schneller da nur kopiert wird was sich seit dem letzten >> Backup geändert hatte. > > > Und Du bist ganz sicher, dass das System immer weiss, welche > Dateien verändert, erstellt oder gelöscht wurden? Ja, schliesslich führt das Filesystem Buch. Der Default bei rsync ist der Check des Datums der letzten Änderung _und_ der Dateigröße. Damit läufst du einmal durch den Dateibaum von HD und Backupmedium und hast alles was sich seit dem letzten Backup auf diese HD geändert hat. Ganz paranoide können auch mit Checksums arbeiten. Findet rsync eine Datei die auf beiden Seiten gleich ist wird eine Checksum berechnet. Ist sie ungleich wird kopiert. Nicht anzuraten bei einem größeren Mediaarchiv. > Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener > Erfahrung, dass auch Linux Daten verliert. Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind natürlich die Änderungen seit dem letzten Backup weg. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Günter Frenz <usenet-01@guefz.de> |
|---|---|
| Date | 2016-10-03 10:38 +0200 |
| Message-ID | <20161003103855.6e4f5160@corinnis.midgard> |
| In reply to | #274914 |
Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: > On 10/03/2016 08:35 AM, Walter Schmid wrote: > > Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener > > Erfahrung, dass auch Linux Daten verliert. Bitte ein Beispiel... > Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind > natürlich die Änderungen seit dem letzten Backup weg. Hatte ich auch noch nie außerhalb von Hardwareschäden oder versehentlichem Löschen durch den User. Über die Jahre hinweg habe ich als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, mit BtrFS zu spielen. Günter
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-03 10:42 +0200 |
| Message-ID | <nst36t$es$1@news.bawue.net> |
| In reply to | #274927 |
On 10/03/2016 10:38 AM, Günter Frenz wrote: > Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: > >> On 10/03/2016 08:35 AM, Walter Schmid wrote: > >>> Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener >>> Erfahrung, dass auch Linux Daten verliert. > > Bitte ein Beispiel... > >> Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind >> natürlich die Änderungen seit dem letzten Backup weg. > > Hatte ich auch noch nie außerhalb von Hardwareschäden oder > versehentlichem Löschen durch den User. Über die Jahre hinweg habe ich > als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, mit > BtrFS zu spielen. BTRFS lass ich noch bleiben, da sind noch zuviele Probleme drin. Siehe auch letztens der RAID-Code. ext4 und XFS waren hier bisher problemlos. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Günter Frenz <usenet-01@guefz.de> |
|---|---|
| Date | 2016-10-03 11:00 +0200 |
| Message-ID | <20161003110042.3453ef3b@corinnis.midgard> |
| In reply to | #274928 |
Am Mon, 3 Oct 2016 10:42:40 +0200 schrieb Gerrit Heitsch: > On 10/03/2016 10:38 AM, Günter Frenz wrote: > > Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: > > > >> On 10/03/2016 08:35 AM, Walter Schmid wrote: > > > >>> Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener > >>> Erfahrung, dass auch Linux Daten verliert. > > > > Bitte ein Beispiel... > > > >> Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind > >> natürlich die Änderungen seit dem letzten Backup weg. > > > > Hatte ich auch noch nie außerhalb von Hardwareschäden oder > > versehentlichem Löschen durch den User. Über die Jahre hinweg habe > > ich als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, > > mit BtrFS zu spielen. > > BTRFS lass ich noch bleiben, da sind noch zuviele Probleme drin. > Siehe auch letztens der RAID-Code. ext4 und XFS waren hier bisher > problemlos. Da wo ich das jetzt verwende, habe ich ein normales Softraid von Linux als Unterlage im Einsatz und nutze BtrFS erst mal nur als normales Dateisystem. Das sollte ja schon vernünftig laufen. Günter
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-03 11:07 +0200 |
| Message-ID | <nst4l2$18c$1@news.bawue.net> |
| In reply to | #274931 |
On 10/03/2016 11:00 AM, Günter Frenz wrote: > Am Mon, 3 Oct 2016 10:42:40 +0200 schrieb Gerrit Heitsch: > >> On 10/03/2016 10:38 AM, Günter Frenz wrote: >>> Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: >>> >>>> On 10/03/2016 08:35 AM, Walter Schmid wrote: >>> >>>>> Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener >>>>> Erfahrung, dass auch Linux Daten verliert. >>> >>> Bitte ein Beispiel... >>> >>>> Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind >>>> natürlich die Änderungen seit dem letzten Backup weg. >>> >>> Hatte ich auch noch nie außerhalb von Hardwareschäden oder >>> versehentlichem Löschen durch den User. Über die Jahre hinweg habe >>> ich als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, >>> mit BtrFS zu spielen. >> >> BTRFS lass ich noch bleiben, da sind noch zuviele Probleme drin. >> Siehe auch letztens der RAID-Code. ext4 und XFS waren hier bisher >> problemlos. > > Da wo ich das jetzt verwende, habe ich ein normales Softraid von Linux > als Unterlage im Einsatz und nutze BtrFS erst mal nur als normales > Dateisystem. Das sollte ja schon vernünftig laufen. Dann viel Spass... Meine Erfahrungen mit CoW-Filesystemen, primär ZFS, sind ziemlich gemischt. Es funktioniert ziemlich gut mit Snapshots, Clones usw... Aber es fragmentiert fürchterlich (bei einer SSD nicht mehr ganz so das Problem) und wenn man die Scrub-Funktion benutzt ist ECC-RAM Pflicht. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2016-10-03 11:30 +0200 |
| Message-ID | <e5emp1Ft796U2@mid.individual.net> |
| In reply to | #274933 |
Am 03.10.2016 um 11:07 schrieb Gerrit Heitsch: > On 10/03/2016 11:00 AM, Günter Frenz wrote: >> Am Mon, 3 Oct 2016 10:42:40 +0200 schrieb Gerrit Heitsch: >> >>> On 10/03/2016 10:38 AM, Günter Frenz wrote: >>>> Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: >>>> >>>>> On 10/03/2016 08:35 AM, Walter Schmid wrote: >>>> >>>>>> Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener >>>>>> Erfahrung, dass auch Linux Daten verliert. >>>> >>>> Bitte ein Beispiel... >>>> >>>>> Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind >>>>> natürlich die Änderungen seit dem letzten Backup weg. >>>> >>>> Hatte ich auch noch nie außerhalb von Hardwareschäden oder >>>> versehentlichem Löschen durch den User. Über die Jahre hinweg habe >>>> ich als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, >>>> mit BtrFS zu spielen. >>> >>> BTRFS lass ich noch bleiben, da sind noch zuviele Probleme drin. >>> Siehe auch letztens der RAID-Code. ext4 und XFS waren hier bisher >>> problemlos. >> >> Da wo ich das jetzt verwende, habe ich ein normales Softraid von Linux >> als Unterlage im Einsatz und nutze BtrFS erst mal nur als normales >> Dateisystem. Das sollte ja schon vernünftig laufen. > > Dann viel Spass... Meine Erfahrungen mit CoW-Filesystemen, primär ZFS, > sind ziemlich gemischt. Es funktioniert ziemlich gut mit Snapshots, > Clones usw... Aber es fragmentiert fürchterlich (bei einer SSD nicht > mehr ganz so das Problem) und wenn man die Scrub-Funktion benutzt ist > ECC-RAM Pflicht. > > Gerrit In /etc/cron.weekly ein /bin/btrfs balance start -dusage=70 /mnt/data hält das hier ganz gut unter Kontrolle.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-10-03 11:34 +0200 |
| Message-ID | <nst681$1n5$1@news.bawue.net> |
| In reply to | #274939 |
On 10/03/2016 11:30 AM, Michael Bode wrote: > Am 03.10.2016 um 11:07 schrieb Gerrit Heitsch: >> On 10/03/2016 11:00 AM, Günter Frenz wrote: >>> Am Mon, 3 Oct 2016 10:42:40 +0200 schrieb Gerrit Heitsch: >>> >>>> On 10/03/2016 10:38 AM, Günter Frenz wrote: >>>>> Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: >>>>> >>>>>> On 10/03/2016 08:35 AM, Walter Schmid wrote: >>>>> >>>>>>> Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener >>>>>>> Erfahrung, dass auch Linux Daten verliert. >>>>> >>>>> Bitte ein Beispiel... >>>>> >>>>>> Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind >>>>>> natürlich die Änderungen seit dem letzten Backup weg. >>>>> >>>>> Hatte ich auch noch nie außerhalb von Hardwareschäden oder >>>>> versehentlichem Löschen durch den User. Über die Jahre hinweg habe >>>>> ich als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, >>>>> mit BtrFS zu spielen. >>>> >>>> BTRFS lass ich noch bleiben, da sind noch zuviele Probleme drin. >>>> Siehe auch letztens der RAID-Code. ext4 und XFS waren hier bisher >>>> problemlos. >>> >>> Da wo ich das jetzt verwende, habe ich ein normales Softraid von Linux >>> als Unterlage im Einsatz und nutze BtrFS erst mal nur als normales >>> Dateisystem. Das sollte ja schon vernünftig laufen. >> >> Dann viel Spass... Meine Erfahrungen mit CoW-Filesystemen, primär ZFS, >> sind ziemlich gemischt. Es funktioniert ziemlich gut mit Snapshots, >> Clones usw... Aber es fragmentiert fürchterlich (bei einer SSD nicht >> mehr ganz so das Problem) und wenn man die Scrub-Funktion benutzt ist >> ECC-RAM Pflicht. >> >> Gerrit > > In /etc/cron.weekly ein > > /bin/btrfs balance start -dusage=70 /mnt/data > > hält das hier ganz gut unter Kontrolle. Wobei es schon etwas komisch ist wenn ein Filesystem für gute Performance einen Cronjob braucht. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2016-10-03 13:50 +0200 |
| Message-ID | <e5euvrFmj9U1@mid.individual.net> |
| In reply to | #274941 |
Am 03.10.2016 um 11:34 schrieb Gerrit Heitsch: > On 10/03/2016 11:30 AM, Michael Bode wrote: >> Am 03.10.2016 um 11:07 schrieb Gerrit Heitsch: >>> On 10/03/2016 11:00 AM, Günter Frenz wrote: >>>> Am Mon, 3 Oct 2016 10:42:40 +0200 schrieb Gerrit Heitsch: >>>> >>>>> On 10/03/2016 10:38 AM, Günter Frenz wrote: >>>>>> Am Mon, 3 Oct 2016 08:52:14 +0200 schrieb Gerrit Heitsch: >>>>>> >>>>>>> On 10/03/2016 08:35 AM, Walter Schmid wrote: >>>>>> >>>>>>>> Ich habe dieses Problem grundsätzlich nie, weiss aber aus eigener >>>>>>>> Erfahrung, dass auch Linux Daten verliert. >>>>>> >>>>>> Bitte ein Beispiel... >>>>>> >>>>>>> Hatte ich noch nie wenn es nicht ein Hardwareschaden war. Dann sind >>>>>>> natürlich die Änderungen seit dem letzten Backup weg. >>>>>> >>>>>> Hatte ich auch noch nie außerhalb von Hardwareschäden oder >>>>>> versehentlichem Löschen durch den User. Über die Jahre hinweg habe >>>>>> ich als Dateisysteme ext2/3/4 und XFS verwendet und fange jetzt an, >>>>>> mit BtrFS zu spielen. >>>>> >>>>> BTRFS lass ich noch bleiben, da sind noch zuviele Probleme drin. >>>>> Siehe auch letztens der RAID-Code. ext4 und XFS waren hier bisher >>>>> problemlos. >>>> >>>> Da wo ich das jetzt verwende, habe ich ein normales Softraid von Linux >>>> als Unterlage im Einsatz und nutze BtrFS erst mal nur als normales >>>> Dateisystem. Das sollte ja schon vernünftig laufen. >>> >>> Dann viel Spass... Meine Erfahrungen mit CoW-Filesystemen, primär ZFS, >>> sind ziemlich gemischt. Es funktioniert ziemlich gut mit Snapshots, >>> Clones usw... Aber es fragmentiert fürchterlich (bei einer SSD nicht >>> mehr ganz so das Problem) und wenn man die Scrub-Funktion benutzt ist >>> ECC-RAM Pflicht. >>> >>> Gerrit >> >> In /etc/cron.weekly ein >> >> /bin/btrfs balance start -dusage=70 /mnt/data >> >> hält das hier ganz gut unter Kontrolle. > > Wobei es schon etwas komisch ist wenn ein Filesystem für gute > Performance einen Cronjob braucht. Irgendwo im der btrfs FAQ steht, dass btrfs das mal selbst können soll. Aber ja, das ist vorerst mal ein Nachteil, den man sich einhandelt.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | ger.ct
csiph-web