linux-nerds.org

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Kopia - Mounten einer Sicherung

Verschoben Kopia

1 Beiträge 1 Kommentatoren 206 Aufrufe

FrankM

schrieb am

Wenn man nicht zu einem Repository verbunden ist, muss man das natürlich als ersten Schritt machen.

kopia repo connect server --url=https://URL:51515 --override-username=USERNAME --override-hostname=HOSTNAME

Wir haben erfolgreich ein paar Backups erstellt, die kann man sich mittels

kopia snap ls

anzeigen lassen.

frank@frank-MS-XXXX:~$ kopia snap ls
frank@frank-MS-XXXX:/home/frank
  2020-08-06 18:16:25 CEST kb9e50ff5bxxxxxxxxx5d40a5d0861 6.9 GB drwxr-xr-x files:8597 dirs:2297 (latest-10)
  2020-08-06 18:58:36 CEST k8b2d8e01dd85xxxxxxxxxxxb50d86655b3 6.9 GB drwxr-xr-x files:8532 dirs:2324 (latest-9,hourly-5)
  2020-08-06 19:15:28 CEST kf15aa39883ca3xxxxxxxxxxx34f78f3ad 6.9 GB drwxr-xr-x files:8532 dirs:2325 (latest-8)
  2020-08-06 19:27:15 CEST k23b109bc58c51fxxxxxxxxxxxxxb979f131e 6.9 GB drwxr-xr-x files:8532 dirs:2325 (latest-7)
  2020-08-06 19:35:13 CEST keca25724dce381exxxxxxxxxxxxde5e94034 6.9 GB drwxr-xr-x files:8532 dirs:2325 (latest-6,hourly-4)
  2020-08-06 20:00:34 CEST k9724e9b951b67xxxxxxxxxxxx24f62e405 6.9 GB drwxr-xr-x files:8565 dirs:2325 (latest-5)
  2020-08-06 20:47:05 CEST kb7087f60045dbbdxxxxxxxxxxxxxf24d9b 6.9 GB drwxr-xr-x files:8568 dirs:2326 (latest-4,hourly-3)
  2020-08-06 21:19:12 CEST kc20a42fdbf0412bxxxxxxxxxxxx6c7b37c 6.9 GB drwxr-xr-x files:8566 dirs:2326 (latest-3)
  2020-08-06 21:23:56 CEST ka4c51e75e21ee16xxxxxxxxxxxxxxcb873 6.9 GB drwxr-xr-x files:8567 dirs:2326 (latest-2,daily-2,hourly-2)
  2020-08-07 18:32:17 CEST k50b0f91477fe6744xxxxxxxxxxxxxx02280 7 GB drwxr-xr-x files:8584 dirs:2342 (latest-1,annual-1,monthly-1,weekly-1,daily-1,hourly-1)

Wir machen einen Mountpoint

mkdir /tmp/kopia

Wir mounten die Sicherung

kopia mount k50b0f91477fe6744xxxxxxxxxxxxxx02280 /tmp/kopia

Nun wird sie Sicherung nach /tmp/kopia gemountet. Nach einer kurzen Wartezeit (7GB) können wir uns die Sicherung ansehen.

Also, nichts wirklich aufregendes. Funktioniert, wie erwartet.

F

Debian Bookworm 12.5 released
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Linux linux debian
3

0 Stimmen

3 Beiträge

146 Aufrufe

F

Und hier taucht es dann auf -> https://www.debian.org/News/2024/20240210
F

NanoPi R2S - Firewall mit VLan und DHCP-Server
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben NanoPi R2S nanopir2s linux
2

0 Stimmen

2 Beiträge

767 Aufrufe

F

Nachdem ich die Tage feststellen musste, das irgendwas mit dem Gerät nicht stimmte, bekam keine DNS Auflösung über die Konsole, habe ich das heute mal eben neuinstalliert.

Armbian ist ja immer was spezielles 🙂 Hat sich bis heute nix dran geändert.....

Ok, dann heute mal eben ein neues Image erstellt. Download Gewählt habe ich das Armbian Buster.

Image auf die SD-Karte, eingeloggt. Alles wie oben erstellt und abgespeichert. Neustart, geht wieder alles. 😍
root@192.168.3.15's password: _ _ _ ____ ____ ____ | \ | | __ _ _ __ ___ _ __ (_) | _ \|___ \/ ___| | \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \ | |\ | (_| | | | | (_) | |_) | | | _ < / __/ ___) | |_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.11-rockchip64 System load: 2% Up time: 11 min Memory usage: 10% of 978M IP: 192.168.3.15 192.168.1.1 192.168.2.1 CPU temp: 61°C Usage of /: 5% of 29G Last login: Sun Dec 6 12:28:10 2020 from 192.168.3.213 Kernelversion root@nanopi-r2s:~# uname -a Linux nanopi-r2s 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux ip a oot@nanopi-r2s:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.15/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 6360sec preferred_lft 6360sec inet6 2a02:908:xxxxxx/64 scope global dynamic mngtmpaddr valid_lft 7196sec preferred_lft 596sec inet6 fe80::b0b5:10ff:fe38:9e76/64 scope link valid_lft forever preferred_lft forever 3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff 4: lan0.100@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global lan0.100 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever 5: lan0.200@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global lan0.200 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever
Vom Notebook aus funktioniert auch alles. So weit bin ich zufrieden. Jetzt mal langsam anfangen, der Kiste IPv6 beizubringen. Oje, nicht gerade mein Lieblingsthema...

Bis der NanoPi R4S hier ankommt und ein vernünftiges Image hat, vergeht ja noch was Zeit...
F

Kopia - HTTP/S Server
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Kopia kopia linux
3

0 Stimmen

3 Beiträge

1k Aufrufe

F

Ich hatte ein paar Probleme, die ich mir teilweise nicht erklären kann 🤔

Ich möchte den Kopia Server gerne über systemd steuern.
SystemD [Unit] Description=Kopia Server After=syslog.target After=network.target [Service] Type=simple User=kopia Group=kopia ExecStart=/usr/bin/kopia server --tls-cert-file /home/kopia-server/fullchain.pem --tls-key-file /home/kopia-server/privkey.pem --htpasswd-file /home/kopia-server/.htpasswd --address <IPv4>:51515 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target
Danach
systemctl daemon-reload systemctl start kopia-server
Mit
systemctl status kopia-server
kann man sich den Status anzeigen lassen.
Client Rechner
Auf dem Client, der das Backup zum Server schicken soll, machen wir dann folgendes.
USER@HOSTNAME:~$ kopia repo connect server --url=https://<DOMAIN>:51515 --override-username=USER --override-hostname=HOSTNAME Enter password to open repository: Connected to repository API Server. NOTICE: Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use. To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false Alternatively you can remove the file "/home/frank/.config/kopia/repository.config.update-info.json".
Danach steht die Verbindung und wir können Backups hochschieben.
kopia snapshot create $HOME
Damit wird das Homeverzeichnis gesichert. Das initiale Backup, hat 30 Minuten gebraucht.
created snapshot with root kb9e50ff5xxxxxxxxxx265d40a5d0861 and ID cda5c0ffxxxxxxxxxxxxxxa4cb4a367b in 30m28s
Ein späteres Backup, sieht so aus.
USER@HOSTNAME:~$ kopia snapshot create $HOME Snapshotting USER@HOSTNAME:/home/frank ... * 0 hashing, 51 hashed (324.8 MB), 8524 cached (6.6 GB), 0 uploaded (0 B), 0 errors 100.0% Created snapshot with root kc20a4xxxxxxxxxxxx745c6c7b37c and ID d7a96eaxxxxxxxxxxx0961018eacffa in 3m12s
Nach 3 Minuten durch. Zu diesem Zeitpunkt hat sich aber auch nicht wirklich was geändert!
Fazit
Das Tool macht immer noch einen sehr guten Eindruck. Die Geschwindigkeit ist sehr gut. Die Anleitung ist leider unzureichend. Da gibt es so viele Möglichkeiten, da braucht es sehr lange, bis man da mal durchsteigt. Zum Glück, ist das was man normalerweise braucht, recht überschaubar. Bis zum produktiven Einsatz braucht das aber bei mir noch eine Menge mehr Tests.

Was ich noch testen möchte
Verzeichnis mounten Backup testweise wieder herstellen (zumindestens teilweise)
Der Test läuft mit Standard Einstellungen, also z.B. ohne Kompression. Das sollte man dann auch mal testen..

Bitte achtet auf gleiche Versionen auf dem Clienten, wie auf dem Server. Ich meine da ein paar Probleme festgestellt zu haben...
F

checkmk - systemd crasht
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben checkmk checkmk linux
1

0 Stimmen

1 Beiträge

472 Aufrufe

Niemand hat geantwortet
F

Nextcloud Talk
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Nextcloud nextcloud coturn linux talk
5

0 Stimmen

5 Beiträge

812 Aufrufe

F

All I needed to do was setting the permissions to 744 for the archive directory and the symlinks resolved correctly after a reboot of coturn

My turnserver installation on Debian runs as the user turnserver and not as root, nor is the user turnserver in any group owning the letsencrypt directory.
If your turnserver does run as root, it should be fine just adding execute permissions.

I hope this helps some of you.
Quelle: https://help.nextcloud.com/t/lets-encrypt-symlink-breaks-coturn-configuration/70166

Was zum Testen die Tage....
F

Node.js Paketmanager npm Sicherheitsproblem!
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Linux security nodejs linux npm
1

0 Stimmen

1 Beiträge

233 Aufrufe

Niemand hat geantwortet
F

Redis Replication
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Redis linux redis
4

1 Stimmen

4 Beiträge

454 Aufrufe

F

Um die Verbindung zu testen, kann man folgende Befehle nutzen.
redis-cli -h 10.1.1.0 -p 6379 -a <PASSWORD>
und
telnet 10.1.1.0 6379
F

[HOWTO] Verschlüsseltes NAS aufsetzen
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben ROCKPro64 howto linux rockpro64
12

0 Stimmen

12 Beiträge

3k Aufrufe

F

Da btrfs bei mir ja nicht so der Bringer war, Fehler im Image vom Kamil?, Fehler in btrfs? Ich weiß es nicht, also weg damit! Da ich das NAS noch richtig produktiv genutzt hatte, waren die Daten schnell gesichert. Danach das NAS neugestartet, nun sind die beiden Platten nicht mehr gemountet und wir können damit arbeiten.
ACHTUNG! Ich bitte wie immer darum, das Gehirn ab hier einzuschalten! Sonst droht Datenverlust! Aus Sicherheitsgründen gebe ich hier die Laufwerke so an = sdX1 Das X bitte entsprechend austauschen!
Die beiden Platten mit
sudo fdisk /dev/sdX
neu einrichten. Alte Partition weg, neu einrichten usw. Im Detail gehe ich hier jetzt nicht drauf ein. Ich gehe davon aus, das das bekannt ist.
Der Plan
raid_pool0 = sdX1 = /dev/mapper/raid_pool0
raid_pool1 = sdX1 = /dev/mapper/raid_pool1
Verschlüsseln sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 Platten entschlüsseln sudo cryptsetup open /dev/sdX1 raid_pool0 sudo cryptsetup open /dev/sdX1 raid_pool1 RAID1 anlegen sudo mdadm --create /dev/md0 --auto md --level=1 --raid-devices=2 /dev/mapper/raid_pool0 /dev/mapper/raid_pool1 sudo mkfs.ext4 /dev/md0 Script zum Entschlüsseln und Mounten crypt.sh #!/bin/bash ###############################################################################$ # Autor: Frank Mankel # Verschlüsseltes Raid1 einbinden! # # Hardware: # ROCKPro64v2.1 # PCIe SATA Karte # 2St. 2,5 Zoll HDD Platten a 2TB # # Software: # bionic-minimal 0.7.9 # Kontakt: frank.mankel@gmail.com # ###############################################################################$ #Passwort abfragen echo "Passwort eingeben!" read -s password echo "Bitte warten......" #Passwörter abfragen echo -n $password | cryptsetup open /dev/sdX1 raid_pool0 -d - echo -n $password | cryptsetup open /dev/sdX1 raid_pool1 -d - #Raid1 mounten mount /dev/md0 /mnt/raid echo "Laufwerke erfolgreich gemountet!"
Bis jetzt sieht das Raid ok aus, ich werde das die nächsten Tage mal ein wenig im Auge behalten.
[ 82.430293] device-mapper: uevent: version 1.0.3 [ 82.430430] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com [ 108.196397] md/raid1:md0: not clean -- starting background reconstruction [ 108.196401] md/raid1:md0: active with 2 out of 2 mirrors [ 108.240395] md0: detected capacity change from 0 to 2000260497408 [ 110.076860] md: resync of RAID array md0 [ 110.385099] EXT4-fs (md0): recovery complete [ 110.431715] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [57744.301662] md: md0: resync done.