mein WireGuard
https://tailscale.com/ (3 User und 100 Geräte kostenfrei)
oder selbst gehostet und unlimitiert:
https://github.com/juanfont/headscale mit https://github.com/ifargle/headscale-webui als GUI (in einer Docker Compose).
Alternativ:
https://netbird.io/ Selbst gehostet: https://docs.netbird.io/selfhosted/selfhosted-quickstart
Alles deutlich angenehmer als WireGuard alleine.
Was ist das denn für ein OS? Die kleine Partition am Anfang für den Bootloader/EFI-Krams scheint mir sinnvoll (wenn sie auch sehr klein ist), aber die anderen beiden Partitionen verstehe ich nicht so ganz. Das Einzige, was mir noch einfallen würde ist, dass diese 1G große Partition eine Art Rettungspartition ist - das ergibt für mich bei einem Server-OS wie Debian aber nicht so viel Sinn (und AFAIK macht Debian das auch nicht).
Ja, ich denke, dass vda3 die ist, die vergrößert werden muss. Du kannst ja auch mit `$ df -h` mal schauen, welche wo hin gemountet wird?
Unterteilung von vda2 und vda3
was steht dazu in der fstab?
bzw wie sieht der output von blkid und lsblk aus?
Was ist das denn für ein OS? Die kleine Partition am Anfang für den Bootloader/EFI-Krams scheint mir sinnvoll (wenn sie auch sehr klein ist), aber die anderen beiden Partitionen verstehe ich nicht so ganz. Das Einzige, was mir noch einfallen würde ist, dass diese 1G große Partition eine Art Rettungspartition ist - das ergibt für mich bei einem Server-OS wie Debian aber nicht so viel Sinn (und AFAIK macht Debian das auch nicht).
Ja, ich denke, dass vda3 die ist, die vergrößert werden muss. Du kannst ja auch mit `$ df -h` mal schauen, welche wo hin gemountet wird?
Die sehr kleine biosboot-Partition ist unproblematisch. Das redhat manual dort rät sogar nur zu 1 mb.
Edit: falschen link gefixt.
Was ist das denn für ein OS? Die kleine Partition am Anfang für den Bootloader/EFI-Krams scheint mir sinnvoll (wenn sie auch sehr klein ist), aber die anderen beiden Partitionen verstehe ich nicht so ganz. Das Einzige, was mir noch einfallen würde ist, dass diese 1G große Partition eine Art Rettungspartition ist - das ergibt für mich bei einem Server-OS wie Debian aber nicht so viel Sinn (und AFAIK macht Debian das auch nicht).
Auf dem Server läuft Debian 12.
Ja, ich denke, dass vda3 die ist, die vergrößert werden muss. Du kannst ja auch mit `$ df -h` mal schauen, welche wo hin gemountet wird?
bud@netcup:~$ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 1,9G 0 1,9G 0% /dev
tmpfs 392M 580K 391M 1% /run
/dev/vda3 8,8G 3,5G 4,9G 42% /
tmpfs 2,0G 16K 2,0G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
/dev/vda2 974M 87M 820M 10% /boot
tmpfs 392M 0 392M 0% /run/user/1000was steht dazu in der fstab?
bud@netcup:~$ sudo nano /etc/fstab
GNU nano 7.2 /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/vda3 during installation
UUID=17661c03-7232-4e59-8c8b-7c7c93246040 / ext4 errors=remount-ro 0 1
# /boot was on /dev/vda2 during installation
UUID=29aa1352-b5cc-4d50-9014-feef2faeee31 /boot ext4 defaults 0 2
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0bzw wie sieht der output von blkid und lsblk aus?
bud@netcup:~$ sudo blkid
/dev/vda2: UUID="29aa1352-b5cc-4d50-9014-feef2faeee31" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d4594129-d7bf-9e4b-8be7-4788062c97aa"
/dev/vda3: UUID="17661c03-7232-4e59-8c8b-7c7c93246040" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="06bc245b-9c69-3843-9484-22bc837cadc0"
/dev/vda1: PARTUUID="47bb14a2-c90c-e348-a341-e95df14e7003"
bud@netcup:~$
bud@netcup:~$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 1024M 0 rom
vda 254:0 0 120G 0 disk
├─vda1 254:1 0 2M 0 part
├─vda2 254:2 0 1G 0 part /boot
└─vda3 254:3 0 9G 0 part /Mich würde vor allem interessieren, wie es zu diesem „Fehler“ gekommen ist, dass ich jetzt die Platte manuell vergrößern muss. Das einzige mir erklärbare wäre, dass ich mich im SCP bei der Frage nach der Partition „verklickt“ habe - aber das kann ich nicht mehr prüfen.
vda1 ergibt für mich ja sogar noch Sinn: Das BIOS abgeschottet vom Rest auf dem Server.
Jain, Protective MBR - ermöglicht dir GPT Partitionstabellen auf BIOS Systemen.
vda2 ist deine eigentliche Bootpartition - sehr klassisch - da sind Bootloader, Kernel und initramfs drauf.
vda3 ist dein eigentliches System.
Ja, so sieht das installierte netcup Debian 12 image wohl aus, wenn man eben nicht "eine große Partition" ausgewählt hat. Hat man das ausgewählt, dann sollte von df -h für vda3 ca 118G als Größe angezeigt werden.
Wenn ich lsblk richtig deute, habe ich für vda insgesamt noch 110 GB unpartitioniert. Zumindest sagt das auch fdisk.
Unpartitionierter Bereich /dev/vda: 110 GiB, 118110552576 Bytes, 230684673 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
Anfang Ende Sektoren Größe
20971520 251656192 230684673 110GKann ich irgendwie die vorahnden Partition vda3 um die 110 GB erweitern, oder muss ich diese dafür zwingend löschen?
Auf dem Server läuft ein produktives System, welches ich ungern neu aufsetzen möchte 
Kann ich irgendwie die vorahnden Partition vda3 um die 110 GB erweitern, oder muss ich diese dafür zwingend löschen?
Auf dem Server läuft ein produktives System, welches ich ungern neu aufsetzen möchte
Wenn du auf Nummer Sicher gehen willst, kannst du auch GParted Live als ISO booten und damit die Partition größer machen.
Dabei sollte nichts kaputt gehen, es ist aber trotzdem eine gute Idee vorher ein Backup oder Snapshot anzufertigen.
vorher ein Backup oder Snapshot anzufertigen
->
parted /dev/vda resizepart 3 100%
## alternativ
# apt install cloud-guest-utils
# growpart -v /dev/vda 3 # <- vda[space]3
resize2fs -p /dev/vda3vda2 ist deine eigentliche Bootpartition - sehr klassisch - da sind Bootloader, Kernel und initramfs drauf.
vda3 ist dein eigentliches System.
Du hast natürlich absolut Recht!
Codeparted /dev/vda resizepart 3 100% resize2fs -p /dev/vda3
Vielen lieben Dank an alle, Olivetti´s Weg hat einwandfrei funktioniert. Danke 
Ich mache das ganz ähnlich. 
Tägliche Backups mit Versionierung und Kopien auf die Storagebox. (Allerdings mit rsync statt scp)
Ob das Löschen von Ordnern/Dateien mit scp auf der box klappt habe ich noch nicht ausprobiert, aber direkt über ssh geht es auf jeden Fall. Das nutze ich auch. z.B.:
ssh u###@u###.your-storagebox.de -p23 "rm -rf dir"
Ob das Löschen von Ordnern/Dateien mit scp auf der box klappt habe ich noch nicht ausprobiert,
Auf jeden Fall geht es mit rsync, werde es dann denke ich damit machen
rsync --progress --delete -e 'ssh -p23' --recursive <Lokales Verzeichnis> <Benutzername>@<Benutzername>.your-netcup.de:<Ziel Verzeichnis>Was ist bei solchen Backup-Zyklen eine sinnvolle Strategie?
Wie lange behaltet ihr tägliche/wöchentliche/monatliche Backups?
Wie lange behaltet ihr tägliche/wöchentliche/monatliche Backups?
Mindestens mal so lange, dass sie garantiert in 1-2 automatisch erstellten Snapshots enthalten sind.
Der Rest hängt vom Projekt bzw. Inhalt ab, da habe ich keine pauschale Antwort.
Wie lange behaltet ihr tägliche/wöchentliche/monatliche Backups?
7/4/6 ist meine standardeinstellung
Wie lange behaltet ihr tägliche/wöchentliche/monatliche Backups?
--keep-within=1d --keep-daily=7 --keep-weekly=4 --keep-monthly=12Dedupliziert und Verschlüsselt durch borgbackup.
Kommt drauf an.
Für die Serverkonfiguration (/etc, cronjobs, Skripte usw.) habe ich 7/4/12
Für andere Dinge wäre das platzmäßig nicht machbar. Da muss ich dann Kompromisse eingehen.
Diesen Prune-Simulator finde ich ganz nett:
