863 lines
19 KiB
Markdown
863 lines
19 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #1e5f8a;
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937;
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5fb3e4;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #0f0f23;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
|
||
}
|
||
section code:not(.hljs) { color: #5fb3e4 !important; }
|
||
section code.hljs { color: #f8f8f8 !important; }
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.klausur {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
section.aufgabe {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.aufgabe footer {
|
||
display: none;
|
||
}
|
||
section.erklaerung {
|
||
font-size: 1.1rem;
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.erklaerung {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
section.erklaerung h1 {
|
||
font-size: 1.5rem;
|
||
color: #1e5f8a;
|
||
margin-bottom: 0.3rem;
|
||
}
|
||
section.erklaerung ul,
|
||
section.erklaerung ol {
|
||
font-size: 1.0rem;
|
||
line-height: 1.4;
|
||
}
|
||
section.erklaerung p {
|
||
font-size: 1.0rem;
|
||
line-height: 1.4;
|
||
}
|
||
section.erklaerung table {
|
||
font-size: 0.9rem;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015b** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Sommersemester 2026**
|
||
|
||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Kapitel 3 – 23.01.2026
|
||
## Speichermedien & Schnittstellen
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
HDD aufgeschraubt neben SSD-Platine
|
||
Mechanisch vs. Elektronisch
|
||
-->
|
||
|
||
---
|
||
|
||
# Speicherkapazität: KB vs. KiB
|
||
|
||
**Das Problem:** Hersteller vs. Betriebssysteme
|
||
|
||
| Dezimal (SI) | Binär (IEC) |
|
||
|--------------|-------------|
|
||
| 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes |
|
||
| 1 MB = 1.000 KB | 1 MiB = 1.024 KiB |
|
||
| 1 GB = 1.000 MB | 1 GiB = 1.024 MiB |
|
||
| 1 TB = 1.000 GB | 1 TiB = 1.024 GiB |
|
||
|
||
**1 TB Festplatte → Windows zeigt ~931 GB!**
|
||
|
||
<!--
|
||
Hersteller: Dezimal (SI-Präfix) - klingt mehr!
|
||
Betriebssysteme: Binär - aber zeigen "GB" statt "GiB"
|
||
Diskrepanz bei 1 TB: 1.000.000.000.000 vs. 1.099.511.627.776 Bytes
|
||
→ 10% Unterschied bei TB-Größen
|
||
Verwirrung für Konsumenten seit Jahrzehnten
|
||
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
|
||
-->
|
||
|
||
---
|
||
|
||
# HDD: Aufbau & Struktur
|
||
|
||
**Komponenten:**
|
||
- **Platter:** Magnetisch beschichtete Scheiben
|
||
- **Spindel:** Dreht mit 5.400-7.200 RPM
|
||
- **Schreib-Lese-Kopf:** Schwebt nm-dünn über Platter
|
||
- **Aktuator:** Bewegt Kopf zur richtigen Spur
|
||
|
||
**Logische Struktur:**
|
||
- **Spuren:** Konzentrische Kreise auf Platter
|
||
- **Sektoren:** Unterteilung der Spuren (512 Bytes)
|
||
- **Zylinder:** Gleiche Spuren aller Platter
|
||
|
||
<!--
|
||
Aufbau seit 1956 (IBM) grundsätzlich gleich
|
||
Platter: Aluminium oder Glas mit Magnetschicht
|
||
Spindelgeschwindigkeit: Desktop 7.200, Laptop 5.400, Server 15.000 RPM
|
||
Head Crash: Schreib-Lese-Kopf berührt Platter → Kratzer → Datenverlust
|
||
Sektor: Kleinste adressierbare Einheit
|
||
LBA (Logical Block Addressing): Abstraktion der physischen Struktur
|
||
-->
|
||
|
||
---
|
||
|
||
# NVMe: Die SSD-Revolution
|
||
|
||
**NVMe = Non-Volatile Memory Express (2011)**
|
||
|
||
**Unterschied zu SATA-SSD:**
|
||
- SATA: Max. ~550 MB/s (AHCI-Protokoll)
|
||
- NVMe: Bis zu 7.000+ MB/s (PCIe direkt)
|
||
|
||
**Form-Faktoren:**
|
||
2,5" (SATA), M.2 (SATA oder NVMe), PCIe-Karte
|
||
|
||
<!--
|
||
NVMe = Non-Volatile Memory Express
|
||
Protokoll speziell für Flash-Speicher entwickelt.
|
||
|
||
SATA wurde für HDDs entwickelt.
|
||
Für SSDs ein Flaschenhals.
|
||
|
||
M.2 ist ein Formfaktor, kein Protokoll!
|
||
M.2 kann SATA oder NVMe sein – prüfen!
|
||
-->
|
||
|
||
---
|
||
|
||
# HDD vs. SSD: Vergleich
|
||
|
||
| Aspekt | HDD | SSD (NVMe) |
|
||
|--------|----:|----------:|
|
||
| Sequentiell | ~150 MB/s | ~3.500 MB/s |
|
||
| Random Read | ~1 MB/s | ~500 MB/s |
|
||
| Latenz | ~10 ms | ~0,02 ms |
|
||
| Preis/TB | ~15€ | ~60€ |
|
||
| Max. Kapazität | 24 TB | 8 TB (Consumer) |
|
||
| Haltbarkeit | 3-5 Jahre | 5-10 Jahre |
|
||
|
||
<!--
|
||
Der Random-Access-Unterschied ist dramatisch.
|
||
500× schneller bei zufälligen Zugriffen.
|
||
|
||
Das ist der Grund, warum SSDs Betriebssysteme
|
||
so viel schneller starten lassen.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Wann HDD, wann SSD?
|
||
|
||
| Anwendung | Empfehlung |
|
||
|-----------|------------|
|
||
| Betriebssystem | SSD (NVMe) |
|
||
| Anwendungen, Spiele | SSD |
|
||
| Video-Editing (Projekte) | SSD |
|
||
| Foto-Archiv | HDD oder SSD |
|
||
| Backup | HDD |
|
||
| NAS / Server | HDD (oder Mix) |
|
||
| Cold Storage | HDD oder Band |
|
||
|
||
<!--
|
||
Die Faustregel:
|
||
- Oft genutzt, schnell gebraucht → SSD
|
||
- Selten genutzt, viel Kapazität → HDD
|
||
|
||
Viele setzen auf beides:
|
||
Kleine SSD für System + große HDD für Archiv.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# HDD vs. SSD – Vertiefung
|
||
|
||
**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
|
||
|
||
**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
|
||
|
||
| Aspekt | HDD | SATA SSD | NVMe SSD |
|
||
|--------|-----|----------|----------|
|
||
| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
|
||
| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
|
||
| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
|
||
| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
|
||
|
||
**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
|
||
|
||
**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Dateisysteme
|
||
## Die Organisation der Daten
|
||
|
||
---
|
||
|
||
# Was macht ein Dateisystem?
|
||
|
||
**Aufgaben:**
|
||
- Dateien in Blöcke aufteilen
|
||
- Speicherort verwalten (Allokation)
|
||
- Verzeichnisstruktur pflegen
|
||
- Metadaten speichern (Name, Datum, Rechte)
|
||
- Integrität sichern (Journaling)
|
||
|
||
**Ohne Dateisystem:**
|
||
Nur eine Folge von Bytes ohne Struktur.
|
||
|
||
<!--
|
||
Das Dateisystem ist die Abstraktionsschicht
|
||
zwischen Anwendungen und rohem Speicher.
|
||
|
||
Es entscheidet:
|
||
- Wie Dateien gefunden werden
|
||
- Wie freier Speicher verwaltet wird
|
||
- Was bei Abstürzen passiert
|
||
-->
|
||
|
||
---
|
||
|
||
# FAT32: Der Kompatibilitätskönig
|
||
|
||
**File Allocation Table, 32-bit (1996)**
|
||
|
||
**Vorteile:**
|
||
- Überall lesbar (Windows, Mac, Linux, Kameras, Fernseher...)
|
||
- Einfach, robust
|
||
|
||
**Nachteile:**
|
||
- Max. 4 GB pro Datei
|
||
- Max. 2 TB pro Volume
|
||
- Keine Berechtigungen
|
||
- Kein Journaling
|
||
|
||
**Ideal für:** USB-Sticks, SD-Karten (Kompatibilität)
|
||
|
||
<!--
|
||
4 GB Limit ist das Hauptproblem.
|
||
Ein 4K-Video oder ISO-Image passt oft nicht drauf.
|
||
|
||
Trotzdem: FAT32 ist der kleinste gemeinsame Nenner.
|
||
Wenn Kompatibilität wichtiger ist als Features → FAT32.
|
||
-->
|
||
|
||
---
|
||
|
||
# exFAT: FAT32 ohne Limits
|
||
|
||
**Extended FAT (2006, Microsoft)**
|
||
|
||
**Vorteile:**
|
||
- Keine praktischen Dateigrößen-Limits
|
||
- Breite Unterstützung (seit 2019 auch Linux-Kernel)
|
||
- Für Flash-Speicher optimiert
|
||
|
||
**Nachteile:**
|
||
- Kein Journaling
|
||
- Weniger robust als NTFS/APFS/ext4
|
||
|
||
**Ideal für:** Große Dateien auf portablen Medien
|
||
|
||
<!--
|
||
exFAT ist der Nachfolger von FAT32 für portable Medien.
|
||
SD-Karten über 32 GB sind standardmäßig exFAT.
|
||
|
||
Microsoft hat 2019 die Patente freigegeben.
|
||
Seitdem native Linux-Unterstützung.
|
||
-->
|
||
|
||
---
|
||
|
||
# NTFS: Windows-Standard
|
||
|
||
**New Technology File System (1993)**
|
||
|
||
**Features:**
|
||
- Journaling (Crash-Sicherheit)
|
||
- Dateirechte (ACLs)
|
||
- Kompression, Verschlüsselung
|
||
- Große Dateien und Volumes
|
||
|
||
**Nachteile:**
|
||
- Nur Windows schreibt nativ
|
||
- macOS: Nur lesen
|
||
- Linux: Über ntfs-3g (langsamer)
|
||
|
||
<!--
|
||
NTFS ist seit Windows NT der Standard.
|
||
Alle modernen Windows-Versionen nutzen es.
|
||
|
||
Für Windows-only-Systeme die beste Wahl.
|
||
Für portable Medien: Kompatibilitätsprobleme.
|
||
-->
|
||
|
||
---
|
||
|
||
# APFS: Apple-Modern
|
||
|
||
**Apple File System (2017)**
|
||
|
||
**Features:**
|
||
- Snapshots (Zeitpunkt-Kopien)
|
||
- Copy-on-Write (CoW)
|
||
- Native Verschlüsselung
|
||
- Optimiert für SSDs
|
||
|
||
**Nachteile:**
|
||
- Nur Apple-Geräte
|
||
- Nicht abwärtskompatibel mit HFS+
|
||
|
||
<!--
|
||
APFS ersetzte HFS+ auf allen Apple-Geräten.
|
||
Snapshots ermöglichen Time Machine und APFS-Klone.
|
||
|
||
Copy-on-Write: Daten werden nicht überschrieben,
|
||
sondern neue Versionen werden geschrieben.
|
||
Gut für Integrität und Snapshots.
|
||
-->
|
||
|
||
---
|
||
|
||
# ext4: Linux-Standard
|
||
|
||
**Fourth Extended File System (2008)**
|
||
|
||
**Features:**
|
||
- Journaling
|
||
- Extents (effiziente große Dateien)
|
||
- Online-Defragmentierung
|
||
- Bewährt und stabil
|
||
|
||
**Nachteile:**
|
||
- Windows/macOS können nicht nativ lesen
|
||
- Weniger Features als btrfs/ZFS
|
||
|
||
<!--
|
||
ext4 ist der Standard für Linux-Systeme.
|
||
Evolution: ext (1992) → ext2 → ext3 → ext4
|
||
|
||
Alternativen: btrfs (Snapshots, CoW), XFS, ZFS
|
||
Für Server oft XFS oder ZFS.
|
||
-->
|
||
|
||
---
|
||
|
||
# Dateisysteme: Übersicht
|
||
|
||
| FS | Max. Datei | Journaling | Ideal für |
|
||
|----|----------:|:----------:|-----------|
|
||
| FAT32 | 4 GB | ❌ | Kompatibilität |
|
||
| exFAT | 16 EB | ❌ | Große portable Dateien |
|
||
| NTFS | 16 EB | ✓ | Windows |
|
||
| APFS | 8 EB | ✓ | macOS, iOS |
|
||
| ext4 | 16 TB | ✓ | Linux |
|
||
|
||
<!--
|
||
Die Wahl hängt vom Kontext ab.
|
||
|
||
Portable Medien: FAT32 oder exFAT
|
||
Interne Laufwerke: NTFS, APFS, ext4 je nach OS
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Backup & Archivierung
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Symbolbild: Kaputte Festplatte oder Ransomware
|
||
Das Worst-Case-Szenario
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum Backup?
|
||
|
||
**Realitäten:**
|
||
- HDDs haben 1-2% jährliche Ausfallrate
|
||
- SSDs können ohne Vorwarnung sterben
|
||
- Ransomware verschlüsselt Daten
|
||
- Versehentliches Löschen passiert
|
||
- Diebstahl, Brand, Wasserschaden
|
||
|
||
**Die Frage ist nicht ob, sondern wann.**
|
||
|
||
<!--
|
||
Backblaze veröffentlicht jährliche HDD-Statistiken.
|
||
1-2% Ausfallrate klingt wenig, aber bei 100 Platten...
|
||
|
||
Pixar verlor fast "Toy Story 2" (1998).
|
||
Rettung: Eine Mitarbeiterin hatte ein Home-Backup.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Die 3-2-1-Regel
|
||
|
||
**3** Kopien eurer Daten
|
||
(Original + 2 Backups)
|
||
|
||
**2** verschiedene Medientypen
|
||
(z.B. SSD + HDD, oder lokal + Cloud)
|
||
|
||
**1** Kopie an anderem Ort
|
||
(Offsite: Cloud, anderes Gebäude)
|
||
|
||
<!--
|
||
Herkunft: Peter Krogh, "The DAM Book" (2005)
|
||
|
||
Warum 3 Kopien?
|
||
- Original kann kaputt gehen
|
||
- Backup 1 auch
|
||
- Backup 2 = Sicherheitspuffer
|
||
|
||
Warum 2 Medientypen?
|
||
- Gleiche Medien haben gleiche Schwachstellen
|
||
- Batch-Fehler bei HDDs derselben Charge
|
||
|
||
Warum 1 Offsite?
|
||
- Brand/Wasserschaden zerstört alles vor Ort
|
||
- Ransomware verschlüsselt angeschlossene Laufwerke
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 3-2-1-Backup-Regel – Vertiefung
|
||
|
||
Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
|
||
|
||
| Bedrohung | Schutz durch | Beispiel |
|
||
|-----------|--------------|----------|
|
||
| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
|
||
| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
|
||
| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
|
||
|
||
**Moderne Erweiterung 3-2-1-1-0:**
|
||
- **+1** Air-Gapped (offline, nicht verbunden)
|
||
- **+0** Verifizierte Backups (regelmäßig Restore testen)
|
||
|
||
**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
|
||
|
||
**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
|
||
|
||
---
|
||
|
||
# Backup-Arten
|
||
|
||
**Vollständig (Full):**
|
||
Kompletter Datenbestand jedes Mal.
|
||
Einfach, aber langsam und platzhungrig.
|
||
|
||
**Inkrementell:**
|
||
Nur Änderungen seit dem letzten Backup.
|
||
Schnell, aber Wiederherstellung komplex (Kette).
|
||
|
||
**Differenziell:**
|
||
Änderungen seit dem letzten Voll-Backup.
|
||
Mittelweg zwischen beiden.
|
||
|
||
<!--
|
||
Typisches Schema:
|
||
- Sonntag: Voll-Backup
|
||
- Mo-Sa: Inkrementell oder Differenziell
|
||
|
||
Inkrementell: Schnellstes Backup, langsamste Wiederherstellung
|
||
Differenziell: Kompromiss
|
||
Voll: Langsamstes Backup, schnellste Wiederherstellung
|
||
-->
|
||
|
||
---
|
||
|
||
# Backup in der Praxis
|
||
|
||
**macOS:** Time Machine
|
||
**Windows:** Veeam Agent (kostenlos), Windows Backup
|
||
**Linux:** rsync, Borg, Restic
|
||
**Cloud:** Backblaze, iCloud, Google Drive
|
||
|
||
**Wichtig:**
|
||
- Automatisieren (manuell wird vergessen)
|
||
- Regelmäßig testen (Backup nützt nichts, wenn Restore nicht funktioniert)
|
||
|
||
<!--
|
||
Time Machine: Stündliche Snapshots, APFS-Integration
|
||
Veeam: Enterprise-Level, kostenlose Endnutzer-Version
|
||
rsync: Unix-Klassiker, extrem effizient
|
||
Borg: Deduplizierung + Verschlüsselung
|
||
-->
|
||
|
||
---
|
||
|
||
# Langzeitarchivierung
|
||
|
||
**Probleme:**
|
||
- Bit Rot (Daten degradieren)
|
||
- Format-Obsoleszenz (wer öffnet .wpd?)
|
||
- Hardware-Obsoleszenz (Diskettenlaufwerk?)
|
||
|
||
**Lösungen:**
|
||
- Migration alle 5-10 Jahre auf neue Medien
|
||
- Offene Standards (PDF/A, TIFF, Plain Text)
|
||
- Redundante Kopien
|
||
|
||
<!--
|
||
WordPerfect dominierte die 1980er/90er.
|
||
Heute kann kaum jemand .wpd-Dateien öffnen.
|
||
|
||
Flash-Dateien (.swf) sind seit 2020 praktisch tot.
|
||
Millionen von Websites und Spielen verloren.
|
||
-->
|
||
|
||
---
|
||
|
||
# Archivmedien
|
||
|
||
**LTO-Tapes:**
|
||
- 18 TB pro Band (LTO-9)
|
||
- ~5€/TB
|
||
- 30 Jahre Haltbarkeit
|
||
- Für Cold Storage ideal
|
||
|
||
**M-DISC:**
|
||
- Spezielle DVD/Blu-ray
|
||
- 1.000+ Jahre Haltbarkeit (Herstellerangabe)
|
||
- Für kleine, wichtige Daten
|
||
|
||
**Cloud:**
|
||
- Glacier, Backblaze B2
|
||
- Günstig für Langzeit
|
||
|
||
<!--
|
||
LTO = Linear Tape-Open
|
||
AWS, Google, Netflix nutzen Tape für Archive.
|
||
|
||
M-DISC nutzt anorganische Schicht statt Dye.
|
||
Theoretisch sehr langlebig, praktisch ungetestet.
|
||
|
||
Cloud-Archive haben laufende Kosten.
|
||
Aber: Keine Hardware-Wartung.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Schnittstellen
|
||
|
||
---
|
||
|
||
# USB: Die Universal-Schnittstelle
|
||
|
||
| Version | Jahr | Geschwindigkeit |
|
||
|---------|------|----------------:|
|
||
| USB 1.1 | 1998 | 12 Mbit/s |
|
||
| USB 2.0 | 2000 | 480 Mbit/s (~60 MB/s) |
|
||
| USB 3.0 | 2008 | 5 Gbit/s (~625 MB/s) |
|
||
| USB 3.1 Gen 2 | 2013 | 10 Gbit/s |
|
||
| USB 3.2 Gen 2×2 | 2017 | 20 Gbit/s |
|
||
| USB4 | 2019 | 40 Gbit/s |
|
||
|
||
<!--
|
||
USB = Universal Serial Bus
|
||
|
||
Die Namensgebung ist ein Chaos.
|
||
USB 3.0 wurde nachträglich zu "USB 3.1 Gen 1" umbenannt.
|
||
Dann zu "USB 3.2 Gen 1".
|
||
|
||
Die Industrie verwirrt absichtlich.
|
||
-->
|
||
|
||
---
|
||
|
||
# USB-C: Der Stecker, nicht die Geschwindigkeit
|
||
|
||
**USB-C ist ein Steckertyp, kein Protokoll!**
|
||
|
||
Ein USB-C-Kabel kann sein:
|
||
- USB 2.0 (480 Mbit/s)
|
||
- USB 3.2 (bis 20 Gbit/s)
|
||
- USB4 (40 Gbit/s)
|
||
- Thunderbolt 3/4 (40 Gbit/s)
|
||
|
||
**Am Stecker nicht erkennbar.**
|
||
→ Kabel-Spezifikation prüfen!
|
||
|
||
<!--
|
||
Das ist eine häufige Quelle für Frustration.
|
||
|
||
"Ich habe ein USB-C-Kabel, warum ist es so langsam?"
|
||
Weil es ein USB 2.0-Kabel mit USB-C-Stecker ist.
|
||
|
||
Gute Kabel sind teurer, aber es lohnt sich.
|
||
-->
|
||
|
||
---
|
||
|
||
# Thunderbolt
|
||
|
||
**Thunderbolt 3/4 (2015/2020):**
|
||
- 40 Gbit/s
|
||
- PCIe über Kabel (externe GPUs möglich)
|
||
- DisplayPort integriert
|
||
- USB-C-Stecker
|
||
|
||
**Vorteile:**
|
||
- Sehr schnell
|
||
- Vielseitig (Daten, Video, Strom)
|
||
|
||
**Nachteile:**
|
||
- Teure Kabel
|
||
- Nicht alle USB-C-Ports sind Thunderbolt
|
||
|
||
<!--
|
||
Intel und Apple entwickelten Thunderbolt gemeinsam.
|
||
Lizenzfrei seit 2019.
|
||
|
||
Thunderbolt-Kabel haben oft ein Blitz-Symbol.
|
||
Aber nicht immer.
|
||
-->
|
||
|
||
---
|
||
|
||
# Video-Schnittstellen
|
||
|
||
| Schnittstelle | Max. Auflösung | Features |
|
||
|---------------|---------------:|----------|
|
||
| HDMI 2.0 | 4K/60Hz | ARC, CEC |
|
||
| HDMI 2.1 | 8K/60Hz, 4K/120Hz | VRR, eARC |
|
||
| DisplayPort 1.4 | 8K/60Hz | Daisy-Chain |
|
||
| DisplayPort 2.0 | 16K/60Hz | Mehr Bandbreite |
|
||
|
||
**HDMI:** Consumer-Geräte (TV, Konsolen)
|
||
**DisplayPort:** Computer, Monitore
|
||
|
||
<!--
|
||
HDMI hat Lizenzgebühren, DisplayPort nicht.
|
||
Deshalb ist DP bei Monitoren beliebter.
|
||
|
||
DisplayPort kann Daisy-Chaining:
|
||
Laptop → Monitor 1 → Monitor 2 über ein Kabel.
|
||
|
||
HDMI hat ARC (Audio Return Channel):
|
||
TV schickt Audio an Soundbar über HDMI.
|
||
-->
|
||
|
||
---
|
||
|
||
# Netzwerk
|
||
|
||
**Ethernet:**
|
||
| Standard | Geschwindigkeit |
|
||
|----------|----------------:|
|
||
| Fast Ethernet | 100 Mbit/s |
|
||
| Gigabit | 1 Gbit/s |
|
||
| 2.5 Gigabit | 2,5 Gbit/s |
|
||
| 10 Gigabit | 10 Gbit/s |
|
||
|
||
**WiFi:**
|
||
| Generation | Standard | Geschwindigkeit |
|
||
|------------|----------|----------------:|
|
||
| WiFi 5 | 802.11ac | ~1,3 Gbit/s |
|
||
| WiFi 6 | 802.11ax | ~9,6 Gbit/s |
|
||
| WiFi 7 | 802.11be | ~46 Gbit/s |
|
||
|
||
<!--
|
||
Gigabit-Ethernet ist heute Standard.
|
||
2,5G und 10G verbreiten sich für NAS und Poweruser.
|
||
|
||
WiFi-Geschwindigkeiten sind theoretische Maxima.
|
||
Real: Bruchteil davon, abhängig von Entfernung und Störungen.
|
||
-->
|
||
|
||
---
|
||
|
||
# Welche Schnittstelle für was?
|
||
|
||
| Anwendung | Empfehlung |
|
||
|-----------|------------|
|
||
| Externe SSD | USB 3.2 Gen 2 oder Thunderbolt |
|
||
| USB-Stick | USB 3.0 reicht |
|
||
| Monitor | DisplayPort oder HDMI 2.0+ |
|
||
| NAS im Heimnetz | Gigabit Ethernet |
|
||
| Backup-Platte | USB 3.0 |
|
||
| Video-Editing extern | Thunderbolt |
|
||
|
||
<!--
|
||
Die Schnittstelle muss zum Gerät passen.
|
||
|
||
Externe HDD über Thunderbolt?
|
||
Bringt nichts, die HDD ist der Flaschenhals.
|
||
|
||
NVMe-SSD über USB 2.0?
|
||
Verschwendung, USB ist der Flaschenhals.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: aufgabe -->
|
||
|
||
# Hands-On: Eigene Speicher analysieren
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
1. Welche Laufwerke habt ihr? (SSD, HDD, extern)
|
||
2. Welches Dateisystem nutzt ihr?
|
||
3. Wie ist eure Backup-Situation?
|
||
4. Welche Schnittstellen nutzt ihr?
|
||
|
||
**Tools:**
|
||
- Windows: Datenträgerverwaltung
|
||
- macOS: Festplattendienstprogramm
|
||
- Linux: `lsblk`, `df -h`
|
||
|
||
<!--
|
||
Ziel: Bewusstsein für eigene Infrastruktur.
|
||
|
||
Die meisten wissen nicht, welches Dateisystem
|
||
auf ihrem USB-Stick ist.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
# Lizenz & Attribution
|
||
|
||
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
|
||
|
||
- Erlaubt Teilen & Anpassen mit Namensnennung
|
||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
||
|
||
Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
|
||
|