Skip to content

Kopia - Aufbau und Funktionsweise

Kopia
  • Guten Morgen, heute möchte ich mal ein wenig aufzeigen, wie https://kopia.io/ aufgebaut ist und funktioniert. Ich hatte da am Anfang so ein wenig Probleme mit 🙂

    Client

    Software

    Was gibt es?

    09a96182-795d-4eef-9b09-c52cfaa4f54f-image.png

    kopia CLI

    Man kann bei kopia, wie bei vielen Programme, den Sourcecode runterladen und das Tool selber bauen. Wir können uns aber auch ein passendes Debian-Paket installieren.

    wget  https://github.com/kopia/kopia/releases/download/v0.6.3/kopia_0.6.3_linux_amd64.deb
    dpkg -i kopia_0.6.3_linux_amd64.deb
    

    Dazu gibt es auch noch die Möglichkeit sich die Downloadquellen in APT einzubauen. Das macht auf meinem System leider einen Fehler, habe ich den schon eingereicht?

    Heute kurz im Slack mit Jarek drüber gechattet, Problem gelöst 🙂 Das war das Problem.

     Das Laden der konfigurierten Datei »main/binary-i386/Packages« wird übersprungen, da das Depot »http://packages.kopia.io/apt stable InRelease« die Architektur »i386« nicht unterstützt.
    

    Jarek hat das auf seiner Seite gefixt.

    Aktuell empfehle ich die Installation des .deb Paketes, geht einfach und problemlos.

    Kopia-UI

    desktop app for all supported platforms: Windows, macOS, and Linux

    Bildschirmfoto vom 2020-08-29 10-35-47.png

    Hier hat man auch wieder viel Auswahl. Ein .deb Paket oder ein AppImage z.B. Beide funktionieren sehr gut.

    repo connect

    Was bei mir etwas gedauert hat, war das Verständnis wie kopia die Verbindung z.B. zu einem Kopia Repository Server verarbeitet. Das ist aber, wenn man es mal verstanden hat, relativ einfach.

    Ich connecte so, zu meinem Server.

    kopia repo connect server --url=https://DOMAIN.de:51515/ --override-username=USER --override-hostname=HOSTNAME
    

    Was passiert dann?

    kopia legt folgende Dateien unter /home/USER/.config/kopia an.

    26f93b1d-0765-44f2-a0aa-f09318160379-image.png

    repository.config

    {
      "apiServer": {
        "url": "https://DOMAIN.de:51515",
        "serverCertFingerprint": ""
      },
      "hostname": "HOSTNAME",
      "username": "USER"
    }
    

    Gut, er speichert die Login-Daten hier ab.

    repository.config.kopia-password

    XXXHHHSSSBBBDBBDJDJDJJ
    

    Das Passwort zum Login auf dem Server in gehashter Form.

    repository.config.update-info.json

     {"nextCheckTimestamp":"2020-09-02T16:41:05.804210493+02:00","nextNotifyTimestamp":"2020-08-26T17:41:07.10204226+02:00","availableVersion":"v0.6.3"}
    

    Die Daten, wenn man ein automatisches Backup angelegt hätte.

    Zusammenfassung

    Nach der erfolgreichen Ausführung von kopia repo connect server werden die Daten im o.g. Verzeichnis gespeichert. Das heisst, man muss das danach nicht wieder machen! Kopia kennt jetzt den Login und könnte jederzeit ein

    kopia snapshot create $HOME
    

    ausführen. Ich habe mich beim Testen immer gefragt, wo hat denn das UI die Login-Daten her. Ok, nun weiß ich das, das UI schaut in den abgelegten Daten nach und verbindet sich automatisch mit dem Server!

    Wichtig! Bei einem

    kopia repo disconnect
    

    werden diese Dateien wieder gelöscht!

    Damit ist nun klar, wie das funktioniert. Somit kann man auch sehr einfach das UI Interface nutzen, was keine eingebaute Funktion zum Verbinden mit dem Repository Server hat. Es hat auch noch ein paar andere Unzulänglichkeiten, dazu gibt es aber einen Issue, der auch abgearbeitet ist. Sollte im nächsten Release drin sein.

    Man verbindet zur Zeit über das CLI zum Server und kann danach das UI nutzen 😉

    Server

    Auf dem Server findet man den selben Aufbau.

    drwx------ 2 kopia kopia 4.0K Aug 29 10:16 .
    drwx------ 4 kopia kopia 4.0K Aug 23 08:39 ..
    -rw------- 1 kopia kopia  392 Aug 24 18:14 repository.config
    -rw------- 1 kopia kopia   64 Aug 24 18:14 repository.config.kopia-password
    -rw------- 1 kopia kopia    0 Aug 22 10:10 repository.config.mlock
    -rw------- 1 kopia kopia  143 Aug 24 17:06 repository.config.update-info.json
    

    repository.config

    {
      "storage": {
        "type": "filesystem",
        "config": {
          "path": "/home/kopia/data",
          "dirShards": null
        }
      },
      "caching": {
        "cacheDirectory": "../../.cache/kopia/3d45987959a6d07f",
        "maxCacheSize": 5242880000,
        "maxMetadataCacheSize": 5242880000,
        "maxListCacheDuration": 600
      },
      "hostname": "HOSTNAME",
      "username": "kopia"
    }
    

    repository.config.kopia-password

    Das gehashte Passwort zum Filesystem.

    repository.config.mlock

    Leer. Bin mir nicht ganz sicher, wird vermutlich nur temporär benutzt (lock)

    repository.config.update-info.json

    {"nextCheckTimestamp":"2020-08-25T17:06:04.915833327+02:00","nextNotifyTimestamp":"2020-08-25T17:06:04.915833878+02:00","availableVersion":""}
    

    Auch hier wieder die Daten für einen automatischen Snapshot, wenn man das nutzt.

    Logfile

    Ihr sucht das Logfile des Servers?

    /home/kopia/.cache/kopia
    

    Fazit

    Sehr logisch aufgebaut, wenn man es mal verstanden und durchschaut hat. Das UI sollte sich mit dem nächsten Release auch besser nutzen lassen. Man kann aber aktuell problemlos Snapshots erstellen, was ich aktuell zur Zeit jeden Tag auch mache,

    Aufpassen! Produktiv einsetzen sollte man sich noch sehr gut überlegen, es gibt da ein Problem was dem Coder aufgefallen ist, der nicht so gut ist.

    Aktuell nutze ich weiterhin Restic, fahre aber zweigleisig, da mir Kopia sehr gut gefällt. Vor allen Dingen das UI macht es sehr einfach einen guten Überblick über seine Backups zu behalten.

  • NAS 2023 - Hardware

    Angeheftet Verschoben Linux
    3
    0 Stimmen
    3 Beiträge
    557 Aufrufe
    FrankMF

    Ich war nicht so ganz zufrieden 🙂 Die zwei 4TB 5 1/4 Zoll HDDs müssen jetzt mal weichen.

    20230520_091729.jpg

    Ich habe jetzt wieder einen Proxmox Backup Server im Einsatz, da brauche ich nicht mehr so viel Speicherplatz im NAS. Kleiner, aber wichtiger Nebeneffekt ist der, das ich jetzt ca. 7W eingespart habe. In Zeiten wie diesen, rechnet sich das. Nein, die Investitionskosten rechnen wir jetzt nicht dagegen 😉

    Screenshot_20230520_140727_Voltcraft SEM6000_ergebnis.jpg

    Aktuelle Platten Ausstattung

    1 TB NVMe SSD (Proxmox Systemplatte) 2 * 2,5 Zoll 1TB SSD WD Red (ZFS Pool für mein NAS) 1 * 2,5 Zoll HDD 2TB für Datensicherung
  • Kopia 0.7.0-rc1 Kurztest

    Kopia
    2
    0 Stimmen
    2 Beiträge
    291 Aufrufe
    FrankMF

    Nachdem ich doch ziemlich lange Snapshot Zeiten hatte, habe ich Jarek mal gefragt woran das liegt.

    I guess you could run it in the cloud but latency will be progressively worse
    because it's a chatty protocol sensitive to latency

    Technisch verstehe ich das nicht, aber ich habe dann mal als kurzen Test auf meine lokale SSD einen Snapshot gemacht. Der war nach 2 Minuten (ca. 11GB) fertig. Der zweite Snapshot brauchte ca. 12 Sekunden. Das hört sich schon mal viel besser an, als die Stunden.

    Aktuell ist der Plan den Kopia-Server im Internet zu nutzen damit beerdigt. Das scheint so nicht zu funktionieren. Ich mache da noch einen kurzen Test, diesmal Lokal auf meinem NAS.

  • Kopia 0.7.x released

    Kopia
    1
    0 Stimmen
    1 Beiträge
    198 Aufrufe
    Niemand hat geantwortet
  • Kopia - HTTP/S Server aufsetzen

    Angeheftet Kopia
    1
    0 Stimmen
    1 Beiträge
    347 Aufrufe
    Niemand hat geantwortet
  • Kopia - HTTP/2 deadlock

    Kopia
    1
    0 Stimmen
    1 Beiträge
    181 Aufrufe
    Niemand hat geantwortet
  • Kopia - Mit Snapshots arbeiten

    Kopia
    2
    0 Stimmen
    2 Beiträge
    342 Aufrufe
    FrankMF

    Solltet Ihr mal snaps mit dem Status incomplete haben und möchtet diese loswerden

    :~$ kopia snap ls -i USER@HOST:/home/frank 2020-09-10 16:31:45 CEST k89770cab1061e00ada49efc41075ed34 incomplete:canceled 728.8 MB drwxr-xr-x files:8891 dirs:3033 (incomplete) 2020-09-10 16:40:05 CEST k27f028b63299983167cb0b4a0c85df80 incomplete:canceled 153.8 MB drwxr-xr-x files:1052 dirs:324 (incomplete)

    So was passiert z.B. wenn die Internetleitung rumzickt. Jarek meint, das wäre nicht schlimm, beim nächsten Snapshot wird das gefixt und die Daten genutzt, die schon verarbeitet wurden.

  • Youtube in Grav

    Grav
    1
    0 Stimmen
    1 Beiträge
    503 Aufrufe
    Niemand hat geantwortet
  • Installation von Grav & NGinx & PHP7.2

    Angeheftet Verschoben Grav
    2
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF

    Nachdem ich den ROCKPro64 jetzt auf den Mainline umgestellt habe, lief meine Testinstallation von Grav nicht mehr.

    Hilfreiche Sache um das Problem zu lösen -> https://gist.github.com/GhazanfarMir/03bd1f1f770a3834d47274586d46ea62

    Ich bekam immer 502 Bad Gateway, Grund war ein nicht korrekt gestarteter php-pfm Service.

    rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm start rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm status ● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-08-16 20:15:20 CEST; 21s ago Docs: man:php-fpm7.2(8) Main PID: 3206 (php-fpm7.2) Status: "Processes active: 0, idle: 2, Requests: 3, slow: 0, Traffic: 0.2req/sec" Tasks: 3 (limit: 4622) CGroup: /system.slice/php7.2-fpm.service ├─3206 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf) ├─3207 php-fpm: pool www └─3208 php-fpm: pool www Aug 16 20:15:19 rockpro64v2_0 systemd[1]: Starting The PHP 7.2 FastCGI Process Manager... Aug 16 20:15:20 rockpro64v2_0 systemd[1]: Started The PHP 7.2 FastCGI Process Manager.