partitionierung im bezug auf effizienz und datensicherheit

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
Aiellu
Beiträge: 270
Registriert: 11.05.2007 21:06:25
Lizenz eigener Beiträge: MIT Lizenz

partitionierung im bezug auf effizienz und datensicherheit

Beitrag von Aiellu » 21.05.2007 15:21:48

huhu, habe fragen zur partitionierung, welche mir weder google noch die debianforum-wiki adäquat beantworten konnte. wie das halt so ist: 2 gurus, 3 meinungen. ;-)

hatte debian als zweitsystem zum bereits bestehenden suse auf eine einzige partition installiert, nun möchte ich nachträglich das system etwas aufräumen, absichern gegen z.b. stromausfälle etc., und optimieren.

hintergrundinfos:
festplatten: hda = 120 GB (linux), hdb = 20 GB (backups und archiv)
anwendungsgebiet: desktop, webdesign, spiele =), multimedia, video-aufzeichnung und -bearbeitung, musik, internet, googleearth und alles was sonst noch so spass macht. :D

die 120GB festplatte verfügt über 8MB hardware-cache, sodass ich mir über performance keine gedanken machen muss und diesen aspekt bei der planung unberücksichtigt lassen kann.

bezüglich der partitionierung hab ich mir folgendes überlegt, wobei ich noch infos über das sicherste filesystem bezüglich stromausfälle sowie die *mindestens* zur verfügung zu stellende größe der partitionen brauche, damit mir nicht später plötzlich eine der partitionen voll ist und das system blockiert, quasi um fehlplanung auszuschliessen):

/ (ext3, mindestgrösse = ?)
/home (ext3, größe = alles was geht ... )
/boot (ext3, mindestgröße = ???)
/tmp (ext3, mindestgröße = ???, möchte gerne tmp in extra-partition haben um die log-dateien vom system getrennt zu haben. welche anderen verzeichnisse enthalten noch log-dateien und sollten separiert werden?)
swap (sw, größe = ich hatte 4GB geplant, hab 1GB RAM und aufrüstung auf 2GB sind geplant)

alles andere wie /var, /usr, /bla, ins root mit rein, da ich keine besonderen netzwerkdienste und keine server laufen habe.

was meint ihr?

und was haltet ihr von reiserfs im vergleich zu ext3 im bezug auf datensicherheit und störungs*un*anfälligkeit?

Benutzeravatar
goeb
Beiträge: 348
Registriert: 26.08.2006 18:12:08
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von goeb » 21.05.2007 17:58:35

Ext3 hat bei mir noch nie Probleme gemacht, auch ein paar Stromausfälle hat es überstanden, allerdings hab ich auch schon gegenteiliges gelesen. Wenn du mit den Partitionen flexibel sein willst verwende LVM. Dann kannst du die Volumes nachträglich vergrößern bzw. verkleinern, auch eine weitere Platte einbauen und mitbenutzen sollte kein Problem sein. Zu den Partitionen:
  • /boot kann recht klein sein, schau mal mit du nach was es bei dir belegt, bei mir sind es zur Zeit 13MB.
  • /tmp ist für temporäre Dateien, Logs sollten dort eigentlich nicht liegen, die gehören nach /var/log. Wenn du Videobearbeitung machst kann ein großes /tmp (im GB Bereich) aber sicher nicht schaden.
  • swap brauchst du in der Regel keine 4GB. Wenn du suspend to disk verwenden willst brauchst du mindestens soviel swap wie RAM, aber ansonsten reicht 1GB locker aus. (Allerdings weiß ich nicht wieviel Speicher bei deiner Videobearbeitung gebraucht wird, probiers am besten aus.)

Clio

Beitrag von Clio » 21.05.2007 18:38:29

Da hat goeb recht, 4GB für swap ist verschenkter Platz, bei dem RAM sind schon 1GB fast zu viel.
Logs liegen immer in /var, daher würde ich dafür evtl. 3-4 GB reservieren. Aber man hat ja, trotz logrotate, immer einen Blick auf die logs.
Evtl. würde ich für /home noch eine separate Partition anlegen, wie groß, hängt von Deinen Programmen und Aktionen ab. Platz hast Du ja reichlich.
Den Rest würde ich zusammen auf / legen.

Einen ganz wichtigen Aspekt, nämlich das Backup, würde ich noch einmal überdenken.
Ein Backup auf der gleichen Platte macht nicht viel Sinn. Sollte die Platte mal defekt sein, ist auch Dein Backup nicht mehr zugänglich.
Daher würde ich auf jeden Fall eine externe USB-Platte einsetzen. Die sind heute nicht mehr so teuer und man ist auf jeden Fall auf der sicheren Seite.
Mit z.B. partimage ist eine Partition ruckzuck gesichert und auch restored, dann sind auch 'Spielereien' am System nicht so tragisch.

Ob reiserfs oder ext3 kannst Du hier nachlesen:
http://de.wikipedia.org/wiki/Journaling

Aiellu
Beiträge: 270
Registriert: 11.05.2007 21:06:25
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Aiellu » 21.05.2007 18:50:14

ups, ja stimmt, in /tmp werden die videoaufzeichnungen zwischengespeichert. hab das mit /var verwechselt wo die logs drin landen. also sollte /var seprariert werden. wieviel speicher muss man für diese partition einplanen, wenn es jetzt schon 1,6GB belegt? wieviel mehr ist noch zu erwarten oder wird es sich bei 1.6GB schon eingependelt haben sodass man ca. 2-3GB dafür einplanen kann?

als filesystem werd ich wohl ext3 nehmen, weils erstens länger etabliert ist und zweitens journaling hat.

nach neuen überlegungen würd es nun also so aussehen...

hda1 - swap (sw, größe = 1GB)
hda2 - /boot (ext3, größe = 100MB)
hda3 - /root (ext3, grösse = die hälfe von "alles was übrig bleibt", wegen dem enthaltenen /tmp-verzeichnis für video-aufzeichnungen)
hda4 - /var (ext3, größe = 4GB)
hda5 - /home (ext3, größe = die andere hälfte von "alles was übrig bleibt")

(hdb1 bleibt aussen vor weils nur für backups gemounted wird)

und mal blöd frag: kann man das ganze eigentlich auch realisieren ohne das system neu aufsetzen zu müssen, oder ist das umständlicher als wenn man halt neu installiert (platte putzen und neues netinst starten geht vielleicht schneller als alles von hand umzufriemeln, oder?)? livecd mit geparted hätt ich zwar hier liegen aber so einen radikalen partitionsumzug hab ich noch nie gemacht... :wink:

@clio
vielen dank auch für deine tips. für backups verwende ich wie gesagt eine seperate festplatte mit 20GB größe (hdb1), welche auch noch an einem seperaten ide-anschluss im rechner hängt. sollte somit relativ problemlos sein, ferner liegen hier immer noch an die 3-4 DVDs rum mit dem kompletten home-verzeichnis darauf gebrannt. :P

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 21.05.2007 20:09:46

Was du machen willst hat so ziemlich jeder der länger dabei ist schon gemacht nur um irgendwan festzustellen man ist nicht flexibel --> neu machen

Verw. entweder LVM oder EVMS
- /boot irgendwas zw. 200MB und 1GB je nachdem wie groß der Kernel Eifer ist
- /swap 1-3 GB für deine Zwecke
- der Rest in ein LVM und dann nach Bedarf verteilen

Kein LVM zu verwenden wird dich Haare kosten ... viele Haare.

Als filesystem würde ich ext3 oder was ich überall habe xfs nehmen. reierfs nein weil bei novel rausgeflogen, ergo niemand der es wirklich pflegt und auch sonst hat keiner wirklich Freude daran - imho wird das fs sterben.

Markus

/edit weil ich da was von DVDs lese - das machen noch Leute? Ich meine das rumfingern mit damn-slow-dvd ....

Eine nette, sexy, schnelle Lösung ist
- http://geizhals.at/eu/a239605.html plus eine
- 2,5" SATA HDD
- dann mit rsync jeden Tag (oder so wie ich immer wenn ich Ortswechsel mache bzw. alle 2h) einen sync vom System auf die kleine HDD oder umgekehrt und alles ist fein

DVDs is was für Leute mit zuviel Zeit.

Aiellu
Beiträge: 270
Registriert: 11.05.2007 21:06:25
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Aiellu » 21.05.2007 21:56:01

zu deinen vorschlägen:
hört sich ziemlich plausibel an, meine bedenken bei so einer haarigen aufteilung, wie ich sie mir dachte, sind halt dass man die platte so nicht optimal nutzen kann weil in jeder partition platz verschenkt wird weil man es halt in der theorie nie so genau aufteilen kann wie man es später in der praxis braucht.

das mit lvm klingt gut, gibt es dazu schon in der wiki infos?

---
bezüglich rsync:
zur zeit benutze ich für additional backups (täglich) ein simples selbst geschriebenes script:

(ausführbar mit user-rechten)

Code: Alles auswählen

#!/bin/bash
#
#=========================================================
# backing up chippi's stuff with the following options... 
#---------------------------------------------------------
# -a: leaves Date untouched
# -r: recursive
# -f: force
# -u: updating (only newer and nonexisting files)
# -v: go get some popcorn and enjoy watching
#---------------------------------------------------------
# Last Modification: $date
#=========================================================

#benutzerverzeichnis chippi
echo "backing up /home/chippi..."
cp -faruv /home/chippi /backup/debian

#benutzerverzeichnis root
echo "backing up /root..."
cp -faruv /root /backup/debian

#systemeinstellungen
echo "backing up /etc..."
cp -faruv /etc /backup/debian

#bootkonfiguration
echo "backing up /boot..."
cp -faruv /boot /backup/debian

#verzeichnis mit selbst kompilierten programmen
echo "backing up /usr/local..."
cp -faruv /usr/local /backup/debian/usr
und zum aufräumen (ca. wöchentlich oder bei reorganisation der backup-verzeichnisse) folgendes:

(ausführbar nur mit root-rechten)

Code: Alles auswählen

#!/bin/bash
#
#=========================================================
# washing up chippi's old backup... 
#---------------------------------------------------------
# Last Modification: $date
#=========================================================

echo "washing up..."

rm -rfv /backup/debian/chippi
rm -rfv /backup/debian/root
rm -rfv /backup/debian/etc
rm -rfv /backup/debian/boot
rm -rfv /backup/debian/usr
was gibt es bei rsync für vorteile die meine scipte nicht bedienen können?

(wer die scripte für sich verwenden will muss natürlich seine eigenen usernamen statt "chippi" eingeben sowie das ganze ggf. noch individuell anpassen auf seinen backup-pfad)

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 21.05.2007 22:22:15

Gut, geht für privat und eine Maschine.
Dennoch finde ich all das .sh Zeug in Sachen Backup ist pita++. So wie es den Anschein hat machen das aber noch immer viele Leute. Imho ist das auch überholt. Vor 7-8 Jahren hat jeder sein nettes .sh gepflegt und das war sein ganzer Stolz.

Dann, später sind doch einige draufgekommen das es evtl. besser wäre die Energie zu bündeln und was wirklich gutes zu schreiben. .sh ist in Sachen Performance, Erweiterbarkeit und Wartbarkeit der absolute Müll.

Ich verw. teilweise DAR. Oder für Business Zeug eben spezielle Hardware (aber das ist nicht der Fokus hier).

Meine Meinung für Privat ist
- entweder was fertiges richtig gutes sinnvolles wie DAR oder rsync
- oder einfach gar nix (das ist was für harte Jungs).

Das mit .sh für Backups ist ebenso ein Relikt wie non LVM. Wir sind nicht mehr in den 90zigern.

Der Grund warum ich "eine Syncronisation" meiner privaten Daten mache ist weil ich damit nicht nur ein
- backup (ist kein Backup im eigenlichen Sinne aber you guys get it ...)
- einen up-to-date snapshot von meinen Daten habe (auf der kleinen externen Disk) die überall dabei ist

Imho tut man sich mit rsync (oder für die GUI Leute grsync) nur einen Gefallen:

Das main window
Bild

zusätzliche Einstellungen die ich habe
Bild

die vollständige Zeile

Code: Alles auswählen

-h --exclude vanilla/ --exclude media/  --exclude tmp/ --exclude dev/ --exclude proc/ --exclude sys/
grsync ist nur das GUI zu rsync. Die options (Zeile oben) kann man natürlich auch rsync mitgeben. Ich verw. seit einiger Zeit beide, je nachdem - einmal nutze ich das GUI, einmal CLI (Command Line Interface). Einen cronjob habe ich auch welcher genau das selbe triggert wie ich entweder mit
- GUI oder
- CLI
zusätzlich kann man für ganz wichtige Dinge inotify-tools auf ein Directory ansetzen (immer wenn sich darin was ändert wird _sofort_ gesynct).

Das kann ein dir mit nur wenige MB oder noch weniger sein welches man in den up-to-date snapshot reinschmelzen kann da der ganze snapshot bei mir ca. 30 GB hat und ich natürlich nur einmal am Tag oder so den ganzen tree syncronisiere weil das schon ca. 10min dauert - aber wie gesagt ganz wichtiges Zeug kann ich jede Minute syncronisieren weil es eben nur 1sec oder so dauert und aber in den main tree hineingeschmolzen wird.
Das macht die Sache flexibel, schnell und bietet mir die Möglichkeit mit verschiedensten Methoden und Interfaces einen redundaten up-to-date tree zu haben.

Das ist 21 Jhdt. im Gegensatz zu dem shell script Unsinn ...

Markus

/edit
Da diese klein HDD mit mir on-the-road ist, ist die ganze HDD natürlich ein crypto container
http://feraga.com/node/51

Aiellu
Beiträge: 270
Registriert: 11.05.2007 21:06:25
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Aiellu » 30.05.2007 09:25:08

@meandtheshell

hab mich nun eine weile mit grsync beschäftigt und eigentlich nur eines festgestellt, nämlich dass es das gleich macht wie mein script, es hat mich halt noch dazu inspiriert noch einige zusätzliche cp-parameter sowie mount und unmount in mein script aufzunehmen, jedoch werd ich weiterhin bei meinem kleinen feinen script bleiben denn da weiss ich genau was es macht, während ich mit grsync nicht so recht warm werden kann/will.

ist wie mit selbst kochen oder kochen lassen... selbst gekocht ist immer leckerer. :P

zwischenzeitig hab ich mein debian auch nochmal ganz neu aufgesetzt mit der aufteilung wie folgt, also /boot und /swap als seperate partitionen und der rest in lvm-partitionen.

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 10.06.2007 23:25:44

Aiellu hat geschrieben:@meandtheshell

hab mich nun eine weile mit grsync beschäftigt und eigentlich nur eines festgestellt, nämlich dass es das gleich macht wie mein script,
Lies dir einmal das man file durch. Dein scirpt ist in der Lage vielleicht 5-10% von den features die rsync bietet zu machen.
es hat mich halt noch dazu inspiriert noch einige zusätzliche cp-parameter sowie mount und unmount in mein script aufzunehmen, jedoch werd ich weiterhin bei meinem kleinen feinen script bleiben denn da weiss ich genau was es macht, während ich mit grsync nicht so recht warm werden kann/will.
Ist ja in Ordnung. Nur wie dein Script skaliert kann ich dir auch sagen. Gar nicht. Versuche einmal mit shell script Zeug Daten im mehrere TB Bereich zu bewegen - 6 Monate Asien Rundreiseticket kannst du vor dem Enter drücken schon bestellen.
Oder jemand stellt eine Anforderung, welche du auf der CLI (non interactive) nicht hinbekommst. Dann wirst du früher oder später sowieso bei rsync oder ähnlichem landen.
zwischenzeitig hab ich mein debian auch nochmal ganz neu aufgesetzt mit der aufteilung wie folgt, also /boot und /swap als seperate partitionen und der rest in lvm-partitionen.
Sinnvoll. Du wirst es nicht bereuen.

Markus

maltesimon
Beiträge: 123
Registriert: 13.07.2004 21:52:23

Beitrag von maltesimon » 11.06.2007 10:18:13

Hallo ich bin grade dabei meine Backup Strategie zu ueberarbeiten. Ich habe ein NB mit 80gb das mueste ich regelmaesig sichern 60gb win und 20gb Debian. Es gibt ein Programm das heist bootcd oder so das macht aus dem Installierten Systhem eine :LiveCD damit dachte ich mein Linux zu sichern und fuer/ home nehme ich dann meine 20gb usb hd. Die Win Partition wurde ich auf meinen 2. Rechner mit True Image sichern. Oder sollte ich es anders machen? Wenn ich mit rsync (keine Erfahrung) die Linux und ntfs partition sicher kann ich dann die von Knoppix aus beide zurueck sichern (ink mbr, grub, win Registrie, ...)? Ich ueberleg mir grade eine 80gb usb hd (gebraucht) fur 50e yu holen oder ist das teuer_

Aiellu
Beiträge: 270
Registriert: 11.05.2007 21:06:25
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Aiellu » 17.06.2007 01:28:38

hatte in letzter zeit einiges zu tun daher erst jetzt die antwort:

es gibt für linux mittlerweile sehr viele backup-anwendungen, was mir spontan einfällt sind folgende: mondo/mindi, (g)rsync, tar, cp, dd.

wichtig für die überlegung einer backup-strategie ist erstmal die frage *was* gesichert werden soll, ob das ganze system lauffähig, einzelne daten, nur das /home-verzeichnis, config-files, gepackt und/oder verschlüsselt,

für daten-backups reicht alles was diese daten von A nach B kopieren kann unter erhalt der attribute, vom komprimieren eines backups rate ich persönlich ab, was mit natur der komprimierung ansich zusammen hängt, und damit wie komprimierte daten auf der platte abgelegt werden.

als datenträger für backups eignet sich alles was groß und schnell genug ist die daten in erträglicher geschwindigkeit aufzunehmen, alles weitere ist persönlicher geschmack. wichtig für den backup-datenträger ist einzig, dass er ohne weiteres von einem externen linux wieder gemountet werden kann um auf das backup zugreifen zu können, da sata noch in den kinderschuhen steckt und scsi nicht ohne weiteres von linux gemounted werden kann würde ich persönlich schon mal davon als backup-träger abraten, ebenso fällt alles andere "exotische" als backup-träger ebenfalls flach (imho jedenfalls), das sicherste ist imho eine fest eingebaute extra festplatte welche ausschliesslich zum durchführen der backups gemountet wird. fest eingebaut daher weil was fest eingebaut ist kann nicht von irgendwo runter fallen, und womöglich noch auf den fuss... (murphy's law) :wink:

system-backups erfordern maximale vorbereitung, ein hunterpro fehlerfreies system, spezielle software welche auch den mbr sichern und wiederherstellen kann sowie eine live-cd von der gebootet werden kann denn system-backups sollten nie während dem laufenden betrieb gemacht werden.

ich selbst bin gar kein freund von system-backups und würde dies auch nicht für den reinen privatgebrauch empfehlen. soetwas ist ausschliesslich für den professionellen bereich sinnvoll, wo die downtime so kurz wie möglich sein muss, und die admins in diesem bereich wissen worauf es ankommt. das problem von unfachmässig ausgeführten system-backups lässt sich ziemlich kurz und in einem wort beschreiben: "vererbung" (und zwar von konfigurationsfehlern, versionskonflikten, beschädigten paketen, abhängigkeitsproblemen etc.), also alles was man an einen system vermurksen kann, wird bei einem system-backup mit gesichert, *daher* rate ich persönlich dem reinen privatanwender, und erst recht dem laien, von einem system-backup ab. :wink:

selbst die praxis im professionellen bereich sieht eher so aus dass selbst die faulsten admins ausschliesslich inkremental-backups der daten machen, denn ein server ansich ist in 5 minuten wieder aufgesetzt, aber die arbeits-daten darauf können bei verlust entweder nur schwer oder garnicht ersetzt werden,

falls du zu den ganz totalen backup-freaks mit zuviel geld und zeit gehörst könnte vielleicht raid 6 etwas für dich sein (hardware-raid wohlgemerkt), was bedeutet, dass zwei festplatten parrall aber unabhängig voneinander laufen, dahinter zwei platten als backup-platten in bereitschaft stehen mit haargenau den gleichen daten wie die arbeits-platten, jedoch nicht im laufenden betrieb sind, und zwei parity-platte nur einen job machen, nämlich per prüfsummen-check aufpassen dass "ihre" arbeits-platte nicht ausfällt und immer die korrekten daten liefert, und falls doch mal ausfällt, sofort die backup-platte zuschaltet. damit hat sich dann das thema backup erledigt. und falls dann echt eine platte ausfällt wird diese einfach per hotplug während dem betrieb ausgewechselt und die parity-platte gleicht dann wieder die daten mit der neuen platte an. reduntanter aber auch sicherer gehts kaum. :P

cosmac
Beiträge: 4579
Registriert: 28.03.2005 22:24:30

Beitrag von cosmac » 17.06.2007 02:13:38

Aiellu hat geschrieben:wichtig für den backup-datenträger ist einzig, dass er ohne weiteres von einem externen linux wieder gemountet werden kann um auf das backup zugreifen zu können,
weshalb IDE-Platten nicht mehr als 15 Partitionen haben sollten, auch wenn 63
möglich sind. Über IDE-USB-Adapter angeschlossen, sehen die wie SCSI aus,
und da gehen nur 15.

Einverstanden; bis auf:
Aiellu hat geschrieben:das sicherste ist imho eine fest eingebaute extra festplatte welche ausschliesslich zum durchführen der backups gemountet wird. fest eingebaut daher weil was fest eingebaut ist kann nicht von irgendwo runter fallen, und womöglich noch auf den fuss... (murphy's law) :wink:
naja, solange sicher, bis das defekte Netzteil 5V und 12V verwechselt oder wer
den kompletten Rechner vom Tisch wirft. Wenn mir eine Platte runterfällt, dann
bitte auf den Fuß, dann hat sie noch eine kleine Chance... Ausser natürlich,
sie ist neu und leer :)
Wie wär's mit: "fest eingebaut in einem Rechner, der in einem anderen Gebäude steht"
Aiellu hat geschrieben:... spezielle software welche auch den mbr sichern und wiederherstellen kann
dd? Scripte mögen, aber "spezielle Software"... tsts ;)
Beware of programmers who carry screwdrivers.

cosmac
Beiträge: 4579
Registriert: 28.03.2005 22:24:30

Beitrag von cosmac » 17.06.2007 02:30:46

Aiellu hat geschrieben:falls du zu den ganz totalen backup-freaks mit zuviel geld und zeit gehörst könnte vielleicht raid 6 etwas für dich sein (hardware-raid wohlgemerkt)
tja, und dann fällt nach 3 Jahren der Controller aus und ist nicht mehr lieferbar.
So gesehen ist Software-Raid wieder sicherer...
Ajellu hat geschrieben:damit hat sich dann das thema backup erledigt.
probier mal "rm" mit * und einem Tippfehler. Ein schnelles Raid löscht auch schneller.
Dann reden wir nochmal über den Unterschied zwischen backup und backup :P

ok, ok, ich hör schon auf ;)
Beware of programmers who carry screwdrivers.

Aiellu
Beiträge: 270
Registriert: 11.05.2007 21:06:25
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Aiellu » 17.06.2007 12:20:29

cosmac hat geschrieben:
Aiellu hat geschrieben:falls du zu den ganz totalen backup-freaks mit zuviel geld und zeit gehörst könnte vielleicht raid 6 etwas für dich sein (hardware-raid wohlgemerkt)
tja, und dann fällt nach 3 Jahren der Controller aus und ist nicht mehr lieferbar.
So gesehen ist Software-Raid wieder sicherer...
Ajellu hat geschrieben:damit hat sich dann das thema backup erledigt.
probier mal "rm" mit * und einem Tippfehler. Ein schnelles Raid löscht auch schneller.
Dann reden wir nochmal über den Unterschied zwischen backup und backup :P

ok, ok, ich hör schon auf ;)
*lol* naja was so ein richtig grober schnitzer ist da hilft auch kein raid mehr. daher führe ich z.b. rm nie indirekt und mit variablen ("*") aus sondern entweder per script (um mich von alten backups zu trenenn) oder ausschliesslich direkt und mit eingabe des names des zu löschenden objekts, soviel zeit muss sein, wobei ich persönlich ganz klar den midnightcommander vorziehe und empfehle für das rumwurschteln in dateisystem.

ich ganz persönlich bevorzuge für backups das allereinfachste und simpelste was es gibt, nämlich eine zweite festplatte als backup-platte mit nur einer partition drauf, ein script zum kopieren meiner prsönlicher daten und von zeit zu zeit mal die backup-platte auf dvd gebrannt in mini-tresor, und noch ein backup ausserhalb des rechner-standorts deponiert. insgesamt ergibt sich so ein bestand bei mir von ca. 4-5 backups an unterschiedlichen orten, von unterschiedlichen zeitpunkten und dazu noch das so genannte "first-responder-backup" auf der backup-platte im rechner. so kann man sich dem dauerhaften fortbestand seiner daten "einigermaßen" sicher sein. :wink:

Antworten