| 2 |
allgemeine Kategorie / Tutorials / qman completion |
am: 07. Juni 2025, 13:38:02 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Da mir für qman ein autocomplete fehlte, habe ich mir ein kleines autocomplete Skript für qman geschrieben. Vielleicht könnt ihr es auch gebrauchen.
Wohin das Skript am besten abgelegt wird, entnimmt bitte der bash-complition Dokumentation
Ihr dütft auch gerne Verbesserungen einbringen. 
if type -P qman >/dev/null; then
_qman() {
local CWORD
CWORD="${COMP_WORDS[COMP_CWORD]}"
_get_qman_option() {
local -a option
local -r option_regex='\B-\w\b|--[\w-]+'
mapfile -t option < <(qman --help | grep -oP -- "${option_regex}")
mapfile -t COMPREPLY < <(compgen -W "${option[*]}" -- "${CWORD}")
}
_get_manual() {
local -a manual
mapfile -t manual < <(man -k . | cut -d ' ' -f1 | uniq)
mapfile -t COMPREPLY < <(compgen -W "${manual[*]}" -- "${CWORD}")
}
case "${CWORD}" in
-*)
_get_qman_option
;;
*)
_get_manual
;;
esac
}
complete -F _qman qman
fi
|
|
LG
Sebastian |
   |
| 3 |
allgemeine Kategorie / Tutorials / Re:qman das moderne man |
am: 05. Juni 2025, 18:03:37 |
| Begonnen von Sebastian | Letzter Eintrag von Dietrich |
Ja, schönes Paket
Danke Sebastian (oder ist das zu früh?) 
Mal den Lernmodus einschalten |
| |
| 6 |
allgemeine Kategorie / Allgemeine Diskussionen / Backupstrategien |
am: 04. Juni 2025, 13:46:07 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Ich möchte hier einfach mal berichten, wie ich meine Backups bzw. und/oder meine Langzeitarchivierung mache. Und gleichzeitig die Frage an euch stellen, wie ihr das so macht.
Grundsätzlich teile ich meine Daten wie folgt auf:
- Betriebssystemdaten (Mountpunkt: /)
- Benutzerdaten (Mountpunkt: /home)
- Daten für Langzeitarchivierung
Betriebssystemdaten:
Sind für mich nicht ganz so wichtig, im schlimmsten Fall installiere ich mein Betriebssystem halt noch mal neu. Aus Bequemlichkeitsgründen (damit ich nicht neu installieren muss) mache ich davon hin und wieder ein Backup in mehreren Stufen.
1. Wird bei mir automatisch bei jeder Paketinstallation ein Btrfs Snapshot meiner Betriebssystemdaten (und auch stündlich) erstellt. Davon werden 7 täglich und 2 wöchentliche Snapshots aufbewahrt. Alle Snapshots, die älter oder über diese Anzahl gehen werden automatisch gelöscht, sobald der nächste Snapshot angelegt wird.
2. Hin und wieder sende ich solch einen Snapshot als Datenstrom direkt in ein restic Repository, um es auf meiner externen Festplatte, die ich auch für Langzeitarchivierungen verwende, zu sichern. Dies ermöglicht es mir bei einem defekt meiner internen Festplatte mein Betriebssystem wiederherzustellen (Ist der Bequemlichkeit geschuldet ). Die Deduplizierung der Daten übernimmt hierbei restic, sodass die Datenströme der Betriebssystem Snapshots depubliziert im restic Repository abgelegt werden. Damit nicht unnötig viel Speicherplatz verwendet wird. Ein restic Repository als Speicherort gegenüber dem Differenzzillen Speichern von Snapshots auf ein anderes Btrfs hat den Vorteil, dass ich das Repository auch auf ein anderes Dateisystem übertragen könnte. Zudem kommt eine Differenzielle Btrfs Snaphot Strategie wegen meines Rotationsprinzips nicht in Betracht. Da mir so der Referenz Snapshot irgendwann gelöscht werden würde, den ich zum differenziellen Abgleich brauchen würde.
Benutzerdaten:
Auch hier werden auf meinen lokalen Datenträger Btrfs Snapshots angelegt nur mit einer anderen Rotation:
keep_hourly = 8
keep_daily = 7
keep_weekly = 4
keep_monthly = 1
keep_yearly = 0
|
|
Hier übertage ich aber nicht wie bei den Betriebssystemdaten ganze Snapsots auf meine externe Festplatte. Sondern sortiere hier die relevanten Daten aus und sichere diese direkt in ein restic Repository, sodass auch hier eine Deduplizierung stattfinden kann.
Daten für Langzeitarchivierung:
Daten, die ich aufbewahren möchte, aber selten bis ga nicht mehr ran gehen muss, sichere ich mir in ein Squashfs. Das ich zwecks Langzeitarchivierung hochgradig mit dem zstd Algorithmus auf Stufe 15 komprimiere. Dieses Dateisystem landet als Datei dann auch auf meine externe Festplatte wo ein Btrfs zum Einsatz kommt.
Ein hoch komprimiertes Squashfs bevorzuge ich gegenüber eines einfachen komprimierten Archives im Übrigen wegen der Möglichkeit, Daten per FUSE aus dem Dateisystem holen zu können und bei einen IO Fehler nicht das ganze Archiv/Dateisystem zerstört wird, sondern nur einzelne Daten in ihm. Zudem behält ein Squashfs auch alle Unix Rechte bei etc. Bei einem komprimierten Archiv müsste zudem erst immer das ganze Archiv entpackt werden, (falls es als ein großer Datenstrom angelegt wurde, wie es bei tar der Fall ist) und zudem wäre bei einem defekt alles nach dem defekt so verloren. Das eignet sich also schon mal nicht für Langzeitarchivierung.
Btrfs Konfiguration der externen Festplatte:
Das Btrfs auf der externen Festplatte habe ich mit folgendem Befehl erzeugt:
mkfs.btrfs -d DUP -m DUP -L Archiv /dev/externeplatte
|
|
Auf dieser habe ich ein Subvolumen namens @archiv angelegt, wo die Daten abgelegt werden. Die Daten lege deshalb nicht im Rootverzeichnis des Btrfs ab, weil ich so ein Snapshot von dem Subvolumen @archiv machen kann, um diesen per btrfs send an meine zweite externe Festplatte zu senden.
Jetzt fragt ihr euch bestimmt, warum ich nicht statt dem Datenprofil DUP nicht einfach das Datenprofil RAID1 von Btrfs nutze, damit Btrfs automatisch auf beiden externen Festplatten die Daten spiegelt. Ganz einfach, da ich nicht immer beide Festplatten angeschlossen haben möchte. So verwende ich quasi eine Festplatte als Master Platte und die andere fungiert als weiteres Backup. DUP verwende ich zudem auch für die Daten, weil meine Platte mit 8 TB so groß ist, das ich den ganzen Speicherplatz nicht brauche. Daher nehme ich hier gerne etwas parity auf dem gleichen Datenträger mit. Damit im Falle eines Bitflips auf dem Datenträger Btrfs die Daten reparieren kann.
Meine Btrfs liegen natürlich alle in einen LUKS Volumen. Damit Daten niemals in Klartext auf einem Datenträger landet. Da ich nie weis, ob ich ein Datenträger später vielleicht mal reklamieren oder weggeben möchte. Oder ich auch so meine Hardware mal zu Reparaturzwecken mit der Festplatte weggeben kann, ohne diese ganz ausbauen zu müssen.
LG
Sebastian |
| |
| 7 |
allgemeine Kategorie / Allgemeine Diskussionen / SquashFS Tools 4.7 Released: Bis zu 20% schneller |
am: 04. Juni 2025, 12:35:52 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
https://www.phoronix.com/news/SquashFS-Tools-4.7
Die SquashFS Tools zum Anlegen und verwalten von dem SquashFS haben ein Update bekommen, dass die Erzeugung eines Squashfs bis zu 20 % schneller machen kann. Dies wird hauptsächlich dadurch erreicht, dass nun mehrere Dateien und Verzeichnisse parallel verarbeitet werden können. Und nicht wie bisher sequenziell.
Zurzeit hängt die Version noch im Extra-Testing und ich freue mich schon, sobald diese in extra Repository landet.
An dieser Stelle auch noch mal ein großes Dankeschön an Leute wie Andreas, die die Testing Repos verwenden. Und mit Bug Reports dazu beitragen, dass die meiste Zeit Updates für uns Endanwender so reibungslos wie möglich ablaufen. Vielen Dank, dass ihr die Versionen vorher mehr oder weniger im Alltag Testtest.
Für mich nimmt das Squashfs eine besondere Rolle ein, da ich dieses Dateisystem für Langzeitarchivierung nutze. Und daher Freud es mich, das ich bald solch ein Dateisystem noch schneller erzeugen kann.
LG
Sebastian |
| |
| 8 |
allgemeine Kategorie / Allgemeine Diskussionen / FUSE Verbesserungen für den Linux 6.16 Kernel |
am: 03. Juni 2025, 13:49:51 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Auch FUSE bekommt im 6.16 Kernel Verbesserungen, so das Dateisysteme im User-Space schneller werden.
Bei Interesse siehe hier:
https://www.phoronix.com/news/Linux-6.16-FUSE
Für mich spielt FUSE eine große Rolle, da ich damit mein restic Repository Mounte. Um Daten aus meinem Backup zu holen. Genauso würde FUSE für mich später in verbindung mit rclone noch eine wichtigere Rolle einnehmen.
LG
Sebastian |
| |
| 9 |
allgemeine Kategorie / Allgemeine Diskussionen / Re:Weitere Btrfs Leistungsverbesserungen im Kernel 6.16 |
am: 01. Juni 2025, 15:55:58 |
| Begonnen von Sebastian | Letzter Eintrag von Andreas |
Nein, ich folge so gut es geht dem Fortschritt. Nur, wenn er Nachteile für mich bringt, dann muss ich auf dem älteren verweilen. Den Anstoß zu meinem Forscherdrang gab mir dein Post mit den Änderungen in Kernel 6.16. Das hat mich neugierig gemacht. Ich überfliege oft andere Quellcodes. Mein gesamtes Programmiererkönnen habe ich dadurch erworben indem ich sehe, wie es andere machen. Man kann Dinge 1:1 übernehmen, oder modifizieren, oder nur Schnipsel verwenden. Alles bringt einen weiter.
LG
Andreas |
| |
| 10 |
allgemeine Kategorie / Allgemeine Diskussionen / Re:Weitere Btrfs Leistungsverbesserungen im Kernel 6.16 |
am: 01. Juni 2025, 13:57:27 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Der einzige Verlust, den ich für btrfs und die Datensicherheit sehe ist der, dass nach den Änderungen Dateien, die gerade im Schreibprozess begriffen waren als ein unerwartetes Ende eintrat (Stromausfall, abgezogenes SATA-Kabel etc.) nun komplett verloren sind und nicht wie vorher nur der letzte Block.
|
|
Für mich hört sich das mit vorbehalt gut an, da ich Datensicherheit vor Schnelligkeit bevorzuge. In diesem Fall muss ich aber sagen, durch diesen Zugewinn ist das zu verkraften. Außerdem beim plötzlichen Stromausfall, denke ich, geht immer irgendetwas verloren, was der Natur der Sache geschuldet ist. Da ist kein Dateisystem, völlig immun gegen. Wichtig ist das dadurch das Dateisystem an sich nicht unbrauchbar wird, und höchsten den Daten von letztem Commit "nur" verloren sind (Bei Btrfs ist der Default im übrigens 30 Sekunden bis zum nächsten commit/flush. Ext4 hat hier ein Default von 5 Sekunden). Also, wenn man hier mehr Sicherheit benötigt, kann man hier auch noch was dran schrauben bei btrfs. Von daher, denke ich, kann jeder sein Dateisystem so nutzen wie er es benötigt.
Ich setze in den nächsten Tagen eines meiner Systeme (das KDE-System) auf BTRFS auf und pflege es parallel zu meinen anderen. Die Sache wird sehr spannend!
|
|
Ich wünsche mir für dich wirklich, dass du deinen benötigten Performanceschub dadurch bekommst. Denn Btrfs ist schon ein geiles Filesystem (wenn man gelernt hat damit umzugehen). Zudem sehe ich in COW Dateisysteme als nächste Evolution von Journaling Dateisysteme an (auch wenn man hier Äpfel mit Birnen vergleicht). Ich finde diese Dateisysteme einfach von Prinzip her sinnvoll sicherer, da ja neue Daten immer erst erfolgreich geschrieben werden müssen, bevor die Pointer umgestellt werden. Und selbst wenn da was dran kaputtgeht, dann behält man ja immer noch die alten Daten, weil ja nie etwas überschrieben wird.
PS:
@Andreas,
Dass du dich da so tief einliest, hätte ich jetzt tatsächlich nicht gedacht, das dein Interesse doch so groß zu btrfs geworden ist. Ich dachte schon, du möchtest dein format and forget ext4 auf ewig behalten. 
LG
Sebastian |
| |
Zurück zur Foren-Übersicht.
|
|
|
