Linux-use

NVMe-Backup System

System-Übersicht

Server: STORE2 (Debian 13)

Zweck: Tägliche vollständige OS-Level Disaster Recovery Backups

Backup-Methode: rsync mit Hard Link Deduplication und --one-file-system

Backup-Größe: 130GB pro Generation (apparent), ~37GB real durch Hard Links

Retention: 21 Tage (daily.0 bis daily.20)

Hardware-Konfiguration

Quelle: NVMe System-Laufwerk (/)

Ziel: /mnt/nvme_backup - 1TB HDD (/dev/sdar1, ext4, Label: NVME_BACKUP)

Kapazität: 21 Backup-Generationen bei ~85% HDD-Auslastung (777GB geschätzt)

Hard Link Backup-Technologie

Funktionsweise der Deduplication

• Erste Generation (daily.0): Vollständiges Backup (~130GB apparent)
• Folge-Generationen: Nur geänderte/neue Dateien verbrauchen Speicherplatz
• Unveränderte Dateien: Hard Links zur vorherigen Generation (0 Byte zusätzlich)
• Gemessene Effizienz: 98-99% aller Dateien sind Hard-Linked zwischen Generationen

Realistische Speichernutzung (gemessen)

daily.0: 130G apparent / 7.4GB real   (neueste Generation)
daily.1: 126G apparent / 85.5GB real  (1 Tag alt)  
daily.2: 126G apparent / 4.1GB real   (2 Tage alt)
daily.3: 125G apparent / 5.9GB real   (2 Tage alt)

Durchschnitt: ~37GB real pro Generation
4 Generationen: 147GB total (statt 520GB bei Vollbackups)

Inkrementeller Charakter durch Hard Links

Das System ist pseudo-inkrementell:

• Jede Generation erscheint als vollständiges Filesystem (130GB)
• Tatsächlicher Speicherverbrauch nur für Änderungen
• Wiederherstellung jeder Generation als komplettes System möglich
• Keine Abhängigkeiten zwischen Generationen (jede ist vollständig)

Software-Komponenten

SystemD Services

• Service: nvme-backup.service - OneShot-Service für Backup-Ausführung
• Timer: nvme-backup.timer - Tägliche Ausführung um 03:08 Uhr
• Mail-Service: nvme-backup-mail@.service - Statistische Erfolgs-/Fehlermeldungen

Scripts und Konfiguration

• Backup-Script: /usr/local/sbin/nvme-backup (KEEP=21)
• Mail-Script: /usr/local/sbin/nvme-backup-mailer (erweiterte Statistiken)
• Exclude-Liste: Im Script hardcodiert

Backup-Strategie und Exclude-Konfiguration

rsync-Parameter (finale Konfiguration)

bash

rsync -aAXH --delete --numeric-ids --info=progress2 --one-file-system

Kritische Parameter:

• -H: Preserviert Hard Links zwischen Generationen
• --one-file-system: Bleibt auf Root-Filesystem, ignoriert RAID-Mounts
• --link-dest=daily.1: Erstellt Hard Links zu unveränderten Dateien

Exclude-Liste

bash

RSYNC_EXCLUDES=(
  --exclude="$DST/*"           # Backup-Ziel selbst ausschließen
  --exclude="/proc/"           # Kernel-Prozess-Dateisystem  
  --exclude="/sys/"            # Kernel-System-Dateisystem
  --exclude="/dev/"            # Device-Dateien
  --exclude="/run/"            # Runtime-Daten
  --exclude="/tmp/"            # Temporäre Dateien
  --exclude="/data/"           # RAID-Mount md125 (XFS, 52TB)
  --exclude="/data2/"          # RAID-Mount md126 (EXT4, 61TB)
  --exclude="/lost+found"      # Dateisystem-Recovery
)

Backup-Inhalt (vollständig eingeschlossen)

• System: /usr (21GB), /etc (399MB), /boot (417MB)
• Services: /var (42GB) - Docker-Container, Emby-Metadaten, Systemlogs
• Daten: /home (10.5GB), /srv (9.5GB), /opt (1.5GB)
• Konfiguration: /root (20GB) - Admin-Scripts und Konfigurationen

Mail-Benachrichtigungen (erweiterte Statistiken)

SMTP-Konfiguration

• Provider: GMX (mail.gmx.net:587, TLS)
• Absender: dergagi@gmx.de
• Empfänger: daniel.gareis@gmail.com
• Authentifizierung: /etc/msmtprc (chmod 600)

Mail-Inhalt (Erfolgs-Mails)

• Backup-Statistiken: Größe (apparent/real), übertragene Datenmenge
• Speicherplatz-Metriken: Belegt/verfügbar/Prozent der 1TB HDD
• Retention-Info: Anzahl vorhandener Generationen, geschätzte weitere Kapazität
• System-Status: Nächster Backup-Termin, RAID-Array-Status
• Performance-Daten: Log-Größe, Backup-Dauer-Schätzung

Wartung und Troubleshooting

Service-Kontrolle

bash

systemctl status nvme-backup.service
systemctl list-timers nvme-backup.timer
journalctl -u nvme-backup.service --no-pager

Hard Link Effizienz-Analyse

bash

# Apparent vs Real Size Vergleich
du -sh /mnt/nvme_backup/daily.*
du -sh --apparent-size /mnt/nvme_backup/daily.*

# Hard Link Statistiken
find /mnt/nvme_backup/daily.0 -type f -links +1 | wc -l

Manueller Backup-Test

bash

systemctl start nvme-backup.service
tail -f /mnt/nvme_backup/_logs/run-$(date +%Y-%m-%d)_*.log

Kritische Konfigurationsdetails

--one-file-system Parameter

Essentiell für korrekten Betrieb. Verhindert rsync-Traversierung der gemounteten RAID-Arrays (/data auf md125, /data2 auf md126). Ohne diesen Parameter würden die 113TB RAID-Daten trotz Exclude-Liste vollständig gebackupt werden.

Hard Link Rotation (21 Tage)

• daily.0: Neuestes Vollbackup
• daily.1-20: Hard Link Generationen (nur Änderungen verbrauchen Speicher)
• Rotation: Automatisch durch Script, daily.20 wird zu daily.21, dann gelöscht
• Erste Löschung: Erfolgt erst nach 21 vollständigen Backup-Zyklen

Performance-Charakteristika

• Erstes Backup: ~130GB in 1,5 Stunden (Vollübertragung)
• Folge-Backups: ~5-40GB in 15-60 Minuten (nur Änderungen)
• CPU-Verbrauch: ~12 Minuten CPU-Zeit pro Backup
• Memory Peak: ~5GB während Backup
• Hard Link Effizienz: 98-99% Dateien verlinkt zwischen Generationen
• Durchschnittlicher Speicherverbrauch: 37GB real pro Generation

Kapazitäts-Management

Speicherplatz-Überwachung

• Aktuelle Nutzung: 147GB für 4 Generationen
• Projektion 21 Tage: ~777GB (85% der 916GB HDD)
• Sicherheitspuffer: ~140GB für Variabilität der täglichen Änderungen
• Überwachung: Automatisch via Mail-Statistiken nach jedem Backup

Notfall-Maßnahmen bei Speicherknappheit

bash

# Retention temporär reduzieren
sed -i 's/KEEP=21/KEEP=18/' /usr/local/sbin/nvme-backup

# Oder auf Original zurücksetzen
cp /usr/local/sbin/nvme-backup.backup-7days /usr/local/sbin/nvme-backup

Integration in Gesamtsystem

Drei-Schicht-Backup-Architektur

1. RAID6-Arrays: Live-Redundanz für Nutzdaten (/data, /data2)
2. NVMe-Backup: OS-Recovery mit vollständiger Service-Konfiguration (21 Tage Historie)
3. Mail-Monitoring: Automatische Überwachung mit detaillierten Statistiken

Optimierte Ressourcen-Aufteilung

• RAID-Schutz: 113TB Nutzdaten mit Hardware-Redundanz
• NVMe-Backup: 130GB System-Recovery mit 3-Wochen-Historie
• Hard Link Effizienz: 777GB für 21 Vollbackups (statt 2.7TB ohne Deduplication)

Das System bietet maximale Wiederherstellbarkeit aller Services mit optimaler Speichernutzung durch Hard Link Technologie, intelligente Filesystem-Trennung und erweiterte 21-Tage-Retention für umfassende Disaster Recovery-Szenarien.

STORE2 NVMe Disaster Recovery Dokumentation

Übersicht

Diese Dokumentation beschreibt die vollständige Wiederherstellung des STORE2-Servers nach einem totalen NVMe-SSD-Ausfall. Das Verfahren basiert auf täglichen rsync-Backups mit Hard-Link-Deduplication.

Systemdaten:

• Backup-System: rsync mit --link-dest (21 Generationen)
• Backup-Größe: ~118GB pro Generation
• Recovery-Zeit: 4-5 Stunden gesamt
• Besonderheit: RAID-Arrays sind mit LUKS verschlüsselt!

Voraussetzungen

Hardware-Anforderungen

• Neue NVMe SSD (Minimum: 256GB, Empfohlen: 512GB, Optimal: 1TB)
• Debian 13 Live-USB oder Installations-Medium
• Physischer Zugriff auf STORE2
• Monitor und Tastatur
• Netzwerkkabel für spätere Updates

Kritische Systeminformationen (STORE2 Stand: September 2025)

System-Partitionierung:

• /dev/nvme0n1p1: 222,6GB ext4 (Root-Partition)
• /dev/nvme0n1p5: 15,9GB swap
• Root-UUID: 0bcdb676-123c-4658-925e-9cba9ecf45df

Backup-HDD:

• Device: /dev/sdar1
• Filesystem: ext4
• Label: NVME_BACKUP
• UUID: 1c2b9b3c-f436-404a-9777-aa288477a7a8
• Mount: /mnt/nvme_backup

RAID-Arrays (VERSCHLÜSSELT mit LUKS!):

• md125: RAID6, 20 Disks, 52TB, XFS, verschlüsselt
  • LUKS UUID: a54ac812-bb0e-4228-b3f7-2961fbb74ce7
  • Decrypted: /dev/mapper/cr_md125
  • Filesystem UUID: 9787dc50-bdd5-4054-901c-bf4657db7ab4
  • Mount: /data

• md126: RAID6, 23 Disks, 61TB, EXT4, verschlüsselt
  • LUKS UUID: 82d138cd-958d-42bc-b0f2-08eaa06f447d
  • Decrypted: /dev/mapper/cr_md126
  • Filesystem UUID: 72ee2927-2855-4ebd-a7d0-3d8f4a3450c1
  • Mount: /data2

Netzwerk:

• Interface: enp0s31f6 (NICHT eth0!)
• MAC: 30:9c:23:68:bf:e8
• Hostname: STORE2
• Domain: dergagi.changeip.org

Phase 1: Vorbereitung (30 Minuten)

1.1 Hardware-Vorbereitung

1. Server herunterfahren: shutdown -h now
2. Stromversorgung trennen
3. Defekte NVMe entfernen
4. Neue NVMe einbauen
5. WICHTIG: Backup-HDD (/dev/sdar1) und RAID-Disks NICHT entfernen!

1.2 Informationen dokumentieren (falls System noch läuft)

Folgende Befehle ausführen und Ausgaben sichern:

lsblk -f > /tmp/lsblk-output.txt blkid > /tmp/blkid-output.txt ip link show > /tmp/network-interfaces.txt cat /proc/mdstat > /tmp/raid-status.txt cat /etc/fstab > /tmp/fstab-backup.txt cat /etc/crypttab > /tmp/crypttab-backup.txt

Diese Dateien auf USB-Stick oder per Mail sichern!

Phase 2: Basis-Installation (45 Minuten)

2.1 Debian 13 installieren

1. Von Debian 13 USB/DVD booten
2. Installationstyp: Minimal (ohne Desktop-Umgebung)
3. Partitionierung EXAKT wie Original:
   • /dev/nvme0n1p1: 223GB ext4 für /
   • /dev/nvme0n1p5: 16GB swap
4. Hostname: STORE2 (wichtig!)
5. Root-Passwort: Temporär (wird überschrieben)
6. Netzwerk: NICHT konfigurieren
7. Software: Nur "Standard-Systemwerkzeuge"

2.2 Nach Installation

• System einmal booten lassen
• Als root anmelden
• Herunterfahren: shutdown -h now

Phase 3: Recovery via Live-System (2-3 Stunden)

3.1 Live-System vorbereiten

1. Von Debian Live-USB booten
2. Terminal öffnen
3. Root werden: sudo -i

3.2 Partitionen identifizieren

lsblk -f

Backup-HDD finden (Label: NVME_BACKUP)

blkid | grep NVME_BACKUP

Neue NVMe-Root finden

blkid | grep nvme0n1p1

3.3 Partitionen mounten

mkdir -p /mnt/new-system mkdir -p /mnt/backup

Neue NVMe mounten

mount /dev/nvme0n1p1 /mnt/new-system

Backup-HDD mounten (normalerweise sdar1)

mount /dev/sdar1 /mnt/backup

Prüfen

df -h | grep mnt

3.4 System wiederherstellen (2-3 Stunden!)

rsync -aAXHv --info=progress2

--exclude='/proc/'

--exclude='/sys/'

--exclude='/dev/'

--exclude='/run/'

--exclude='/tmp/'

--exclude='/mnt/'

/mnt/backup/daily.0/ /mnt/new-system/

Erwartete Werte:

• Dateien: ~1.7 Millionen
• Daten: ~118GB
• Dauer: 2-3 Stunden

Phase 4: System-Anpassung (1 Stunde)

4.1 Chroot vorbereiten

KRITISCH: Exakte Reihenfolge!

mkdir -p /mnt/new-system/{dev,proc,sys,run}

mount --bind /dev /mnt/new-system/dev mount --bind /proc /mnt/new-system/proc mount --bind /sys /mnt/new-system/sys mount --bind /run /mnt/new-system/run mount --bind /dev/pts /mnt/new-system/dev/pts

chroot /mnt/new-system /bin/bash

Test ob chroot funktioniert

ls /root cat /etc/hostname # Sollte "STORE2" zeigen

4.2 Hardware-Anpassungen

Neue UUID ermitteln

blkid | grep nvme0n1p1

Backup

cp /etc/fstab /etc/fstab.backup

fstab editieren

nano /etc/fstab

Syntax prüfen

mount -a

GRUB neu installieren

grub-install /dev/nvme0n1

Sollte zeigen:

Installation finished. No error reported.

update-grub

Initramfs neu bauen

update-initramfs -u -k all

Interface-Namen prüfen

ip link show

/etc/network/interfaces editieren

nano /etc/network/interfaces

iface enp0s31f6 inet dhcp

4.4 Chroot verlassen und unmounten

exit

Unmount in UMGEKEHRTER Reihenfolge!

umount /mnt/new-system/dev/pts umount /mnt/new-system/run umount /mnt/new-system/sys umount /mnt/new-system/proc umount /mnt/new-system/dev umount /mnt/new-system umount /mnt/backup

reboot

Phase 5: Post-Recovery (30 Minuten)

5.1 Erster Boot

Nach dem Boot als root einloggen:

Netzwerk prüfen

ip a ping -c 3 8.8.8.8

Falls kein Netzwerk:

systemctl restart networking

SSH aktivieren

systemctl start ssh systemctl enable ssh

5.2 RAID-Arrays wiederherstellen (VERSCHLÜSSELT!)

WICHTIG: Arrays sind LUKS-verschlüsselt!

Arrays assemblieren

mdadm --assemble --scan

Status prüfen

cat /proc/mdstat

LUKS entsperren (Passwort erforderlich!)

cryptsetup luksOpen /dev/md125 cr_md125 cryptsetup luksOpen /dev/md126 cr_md126

Mounten

mount /dev/mapper/cr_md125 /data mount /dev/mapper/cr_md126 /data2

Prüfen

df -h | grep data

5.3 Docker-Services starten

systemctl status docker

Falls nicht läuft:

systemctl start docker

Container-Status

docker ps -a

Alle Container starten

docker start $(docker ps -aq)

Warten (2-3 Minuten)

docker ps

Apache

systemctl status apache2 curl -k https://localhost/site

Backup-Timer

systemctl status nvme-backup.timer systemctl list-timers | grep backup

Emby

systemctl status emby-server

Fehlerhafte Services

systemctl list-units --failed

Phase 6: Vollständige Verifikation

6.2 Docker-Container prüfen

docker ps --format "table {{.Names}}\t{{.Status}}"

Bei Problemen Logs prüfen:

docker logs CONTAINER-NAME

6.3 RAID-Integrität

mdadm --detail /dev/md125 mdadm --detail /dev/md126

SMART-Status

smartctl -a /dev/sda | grep -E "SMART overall|Reallocated"

Troubleshooting

Problem: GRUB Error "no such device"

1. Von Live-USB booten
2. Chroot-Prozedur wiederholen
3. UUID in /etc/fstab nochmals prüfen
4. update-grub erneut ausführen

Problem: Netzwerk funktioniert nicht

ip link show

Interface-Name notieren (z.B. enp0s31f6)

nano /etc/network/interfaces

Interface-Namen anpassen

systemctl restart networking

Prüfen ob Arrays da sind

cat /proc/mdstat

Manuell entsperren

cryptsetup luksOpen /dev/md125 cr_md125 cryptsetup luksOpen /dev/md126 cr_md126

/etc/crypttab prüfen

cat /etc/crypttab

Sollte beide Arrays enthalten

Problem: Docker-Container starten nicht

systemctl restart docker docker start CONTAINER-NAME docker logs CONTAINER-NAME

Kritische Hinweise

RAID-Verschlüsselung: Die RAID-Arrays md125 und md126 sind mit LUKS verschlüsselt! Das Entschlüsselungs-Passwort wird benötigt. Ohne dieses Passwort sind die 113TB Daten nicht zugänglich.

Interface-Namen: Das Netzwerk-Interface heißt enp0s31f6, NICHT eth0. Dies muss in /etc/network/interfaces angepasst werden.

Docker-Volumes: Alle im Backup enthalten unter /var/lib/docker/volumes/

Backup-HDD: Device /dev/sdar1 mit Label NVME_BACKUP - NIEMALS formatieren!

IP-Adressen: Bei MAC-Änderung könnte DHCP neue IP vergeben.

Notfall-Kontakte

• Zugriff via Live-System immer möglich
• Backup-HDD (/dev/sdar1) ist die Lebensversicherung
• RAID-LUKS-Passwort sicher aufbewahrt?
• Logs in /var/log/ und /root/chatgpt-logs/

Backup-System prüfen

systemctl status nvme-backup.timer systemctl list-timers | grep nvme

Test-Backup

systemctl start nvme-backup.service

Log beobachten

tail -f /mnt/nvme_backup/_logs/run-*.log

HDD als NTFS unter Linux richtig formatieren

Szenario: Raid-Platte geht noch, liefert aber sporadische Fehler in dmesg z.B. -> wird im Raid ersetzt -> ist dann "über" -> kann als Serien-Sammelplatte noch verwendet werden

Damit die Platte auch unter Windows richtig erkannt wird ist folgendes zu beachten:

Partitionstyp muss auf 0x07 (HPFS/NTFS/exFAT) stehen!

Partitionieren mit gdisk

sudo gdisk /dev/sdX

• erst alte Linux Raid Partiton löschen: d -> 1 -> w
• n → Neue Partition anlegen (Eingaben bestätigen oder (falls gewünscht) Start- und Endsektor anpassen)
• 0700 als Typ für NTFS setzen (wird ggf. vorgeschlagen, sonst nachfragen)
• w → Schreiben und gdisk verlassen

Formatieren mit mkfs.ntfs

sudo mkfs.ntfs -f /dev/sdX1

Mounten mit

sudo mkdir -p /mnt/ntfs
sudo mount -t ntfs-3g /dev/sdX1 /mnt/ntfs

Booten überhaupt !!!

Bios 12 ist OK. Kerne laufen beide auf 2.5Ghz.

Beide Karten sind OK und müssen auch beim Booten drin sein

Wenn die Laufwerke vom 4-Ch Sata-Controller ab sind, wir auch gebootet.

Dann können sie Hot-Geplugged werden -> geht :-)

Jetzt testen dass auch alle 27 (!) Laufwerke da sind.

/root/bin/diskserial_sort.sh 

Dann weiter wie im Raidabschnitt beschrieben

mdadm --assemble --scan

Raid-Karten Kernel-Treiber nach Kernelupdate

cd /Nach_Kernelupdate/rr2340-linux-src-v1.7/product/rr2340/linux/ 

make clean
make
make install

Manuelles starten (nach Reboot automatisch)

modprobe rr2340

Grub und Root-Festplatte

in /boot/grub/menu.lst z.B.

kernel /boot/vmlinuz-2.6.31.14-0.6-desktop root=UUID=d06e4d6a-44d7-4f09-9ea3-a4cb8f120770 ...

UUID einer Festplatte herausfinden

blkid /dev/sdq8

Screen-Umgebung

http://linuxwiki.de/screen

Liste aller Screens

screen -ls

Starten

screen -S NAME

Detach

Strg-a d = detach

Reatach

screen -r NAME

ODER Wieder reingehen

screen -x NAME 

Screens beenden

im Screen Strg-a k (wie kill)

Arch Linux AUR Pakete

- tarball herunterladen
- nach /builds entpacken (tar -xzf xxxx.tar.gz)
- dort makepkg
- pacman -U xxxx.pkg.tar.xz

RAR unter Linux

RAR-Archiv testen

rar t xxxxx.rar 

Wake-On-Lan

Netzwerkkarte in System->Gerätemanager erlauben und Magic Paket einstellen im Bios PCI aufwecken erlauben Mac-Adresse und Netzwerk-IP wissen

Uni

Linux-Konsolen-Befehl zum Aufwecken auf Uni-Rechner Big-Blue2 aus "Hibernate":

wol -i 132.187.33.255 90:e6:ba:43:c2:dc 

Busfahrer an Uni:

wol -i 132.187.33.255 b8:ac:6f:67:e6:43 

Brücknerstrasse

Aufwecken aus "Standby"

(Bachus)

wol -i 255.255.255.255 00:1e:8c:46:10:8c 

(Myth intern)

wol -i 255.255.255.255 00:14:85:e8:10:4c

Myth PCIe

wol -i 255.255.255.255 00:e0:45:49:00:09

Tool um Windows um Remote-Verbindung schlafen zu legen PowerOff z.B. bei

http://www.chip.de/downloads/Poweroff_21571048.html

Linuxbefehl für OpenSuse um per Konsole zu suspenden:

pm-suspend 

-> Vorsicht: Festplatten verhalten sich komisch

"HDIO_DRIVE_CMD(identify) failed: Invalid exchange" 

bei

 /root/bin/diskserial_sort.sh 

Aufwecken über Fritzbox direkt problemlos möglich.

Remote-Desktop

Big-Blue: SSH auf wolf.physik.uni-wuerzburg.de mit Tunnel: 33889 auf Ziel 132.187.33.133:3389 Dann localhost:33889

Myth: dergagi.dyndns.org normal (ohne Angabe gilt Port 3389)

Bachus: dergagi.dyndns.org:33890

Ordnergröße in Konsole anzeigen

du -sh /home

Für Platzstatus auf Partitionen

df -h

DU-Meter für SuSE/Linux

KTrafficAnalyzer, z.B. über 1-Klick Installation bei http://software.opensuse.org/search

NTM http://netramon.sourceforge.net/eng/index.html

Bandwidth-Monitor für Console, z.B. auch Ubuntu

bwm-ng

bmon

Netzwerk-Geschwindkeit testen

Tool: iperf gibts für Linux, Windows, Mac Server (empfängt Testdaten)

iperf -s

Client (sendet Daten)

iperf -c 192.168.1.60  (Myth)
ipfer -c 192.168.1.66  (Store)

Manuel RPM Pakete installieren

rpm -ihv nedit-5.5-31.8.x86_64.rpm

Locate auf Data/Data2

locate -i -d /data/locatedb "mein suchbegriff"

USB-Device mounten

mount -t ntfs-3g /dev/sdj5 /usb -o force

NTFS Linux

mount -t ntfs-3g /dev/sds1 /mo1

Opensuse: IP über DHCP erneuern

  1.  Open a terminal and su - to root.
  2. Type ifconfig to show the current IP address that you received from DHCP.
  3. Type dhcpcd -k to send the appropriate signals to dhcpcd.
  4. Now bring the interface back up by typing ifup eth0.
  5. Type ifconfig to show the new IP address.

System-Backup-Image von USB-Platte mounten

mount -o loop /media/Data5/store_root.img /mnt/loop/

Verzeichnisse synchronisieren

mit grsync

Devices neu einlesen im laufenden Betrieb ohne Reboot

blockdev --rereadpt /dev/sdx

Laufwerke am RocketRaid neu einlesen im laufenden Betrieb ohne Reboot

Kernelmodul da?

lsmod rr2340

Kernelmodul entfernen/löschen

rmmod rr2340

Kernelmodul wieder laden/starten

modprobe rr2340

KDE Remote Desktop

krdc -> Client

TightVNC -> Client

krfb -> Server (über Konsole z.B. mit Xming starten, wegen Grafik)

Port Forwarding im Router: Kontrolle unter: vi home/root/kde4/share/config/krfbrc

JDownloader

Installieren über Script von Homepage

  1. wget must be installed on system!
  2. Download jd.sh
  http://212.117.163.148/jd.sh
  3. chmod +x jd.sh
  4. start jd.sh -> ./jd.sh

Note: Open jd.sh to read Manual or change Settings!

Starten nach Installation:

java -jar /home/gagi/.jd/JDownloader.jar

One-Click Install auf Konsole

OCICLI <YMP URL>

Cronjobs

Liste

crontab -l

Einträge ändern

crontab -e

dort dann im vi editieren

Data Scrubbing, automatische Suche einmal im Monat nach BadBlocks

In short: Especially if you run a RAID5 array, trigger an active bad block check on a regular basis, or there is a high chance of hidden bad blocks making your RAID unusable during reconstruction.

Normally, RAID passively detects bad blocks. If a read error occurs, the data is reconstructed from the rest of the array, and the bad block is rewritten. If the block can not be rewritten, the defective disk is kicked out of the active array.

Once the defective drive is replaced, reconstruction will cause all blocks of the remaining drives to be read. If this process runs across a previously undetected bad block on the remaining drives, another drive will be marked as failed, making RAID5 unusable. The larger the disks, the higher the odds that passive bad block detection will be inadaquate. Therefore, with today's large disks it is important to actively perform data scrubbing on your array.

With a modern (>=2.6.16) kernel, this command will initiate a data consistency and bad block check, reading all blocks, checking them for consistency, and attempting to rewrite inconsistent blocks and bad blocks.

echo check >> /sys/block/md127/md/sync_action
echo check >> /sys/block/md125/md/sync_action

You can monitor the progress of the check with:

watch -n .1 cat /proc/mdstat

You should have your array checked daily or weekly by adding the appropriate command to /etc/crontab.

Steht für jeden 8. des Monats in Crontab.

If you find yourself needlessly checking your array (like I was) and want to stop it safely, you can either stop the entire array, or:

echo idle >> /sys/block/md127/md/sync_action
echo idle >> /sys/block/md125/md/sync_action

TigerVNC

Start Server

vncserver :1 
vncserver :2 

Kill Server

vncserver -kill :1 

Port 5901

dergagi.selfhost.bz:5901 
dergagi.selfhost.bz:5902 

Auflösung ändern:

im VNC-Fenster (also schon remote)

xrandr -s 1920x1200

XTerm Benutzer wechseln:

su gagi

Autostart

in /etc/rc.local

su gagi -c "vncserver -geometry 1920x1080 -alwaysshared -localhost -dpi 96 :1"

RSYNC volles Systembackup

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/data","/data2","/suse","/rsync-backup"} / /rsync-backup/