Skip to content

Datensicherung zwischen zwei Server

Linux
2 1 778
  • Nehmen wir mal folgende Situation an.

    • einen Server im Internet Server1
    • einen Server im LAN Server2

    Auf dem Server1 liegt eine Datei, die ich gerne einmal am Tag sichern würde. Server2 dient als Ziel zur Datensicherung.

    0_1529324812635_database-1954920_640.jpg

    Wir brauchen

    • Script auf dem Server1
    • Script auf dem Server2

    Für beide Scripte legen wir einen Cronjob an, damit das Ganze vollautomatisch abläuft. Für die Datenübertragung benutzen wir das Programm scp

    scp ermöglicht die verschlüsselte Übertragung zwischen zwei Computern im Netz.

    Script 1

     #!/bin/bash
     ###############################################################################$
     #       Autor: Frank Mankel
     #       Redis Backup-Script
     #
     #       Kontakt: 
     #
     ###############################################################################$
     
     echo "Start Redis Backup-Script"
     
     echo "Daten sichern"
     # Daten kopieren
     cp /var/lib/redis/dump.rdb /home/frank/redis_backup
     
     # Ins Arbeitsverzeichnis wechseln
     cd /home/frank/redis_backup
     
     # Der Datei das aktuelle Datum anhängen
     cp dump.rdb dump.rdb_`date +%d_%b_%Y`
     
     # Den Namen der Datei einer Variablen zuordnen
     file=`find /home/frank/redis_backup -type f -name "*.rdb_*" -printf "%f\n"`
     
     # Den Benutzer ändern
     chown frank:frank dump.rdb*
     
     # Paar Textausgaben falls man das File mal von Hand ausführt
     echo "File kopiert"
     echo "Sie können jetzt die Daten per SCP sichern"
     echo "scp user@google.com:/home/frank/redis_backup/$file ."
     
     # Aus Sicherheitsgründen, lösche ich die Files nach einer bestimmten Zeit.
     # In dieser Zeit wird per Cron das File runter geladen!
     sleep 10m
     rm dump.rdb*
     
     # Fertig ;)
     echo "Scipt beendet"
    

    Script2

    #!/bin/bash
    ###############################################################################$
    #       Autor: Frank Mankel
    #       Redis Backup-Script
    #
    #       Kontakt: 
    #
    ###############################################################################$
    
    scp frank@google.com:/home/frank/redis_backup/dump.rdb_* .
    echo "Datei gesichert"
    
    # Alle Dateien löschen, die älter als 5 Tage sind.
    find /Datei_Pfad/ -name "*.rdb*" -mtime 5 -exec rm {} \;
    

    Bitte den find Befehl erst ohne die Löschfunktion testen!

     -exec rm {} \;
    

    Eine fehlerhafte Eingabe löscht gnadenlos, ohne Rückfrage!

    Für beide Scripte legen wir jeweils einen Crontab an. Da gehe ich hier nicht weiter drauf ein.

    crontab -e
    

    Bleibt noch ein Problem. scp verlangt das Passwort beim Aufruf, nicht gut. Aber auch dafür gibt es eine Lösung.

    Server2

    [user@server2]# ssh-keygen -t rsa -b 2048
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa): # Hit Enter
    Enter passphrase (empty for no passphrase): # Hit Enter
    Enter same passphrase again: # Hit Enter
    Your identification has been saved in /root/.ssh/id_rsa.
    Your public key has been saved in /root/.ssh/id_rsa.pub.
    

    Danach den Key auf Server1 kopieren

    ssh-copy-id user1@server1
    

    Quelle: unix.stackechange.com

    Danach kann man sich ohne Passwort auf dem Server1 anmelden, somit kann das Programm jetzt auch vollautomatisch gestartet werden.

  • Funktionskontrolle heute morgen war o.k. Schreibt die Daten aber noch ins falsche Verzeichnis, da muss ich nochmal ran.

  • 0 Stimmen
    1 Beiträge
    17 Aufrufe
    Niemand hat geantwortet
  • OpenCloud - Storage Backends testen

    OpenCloud opencloud linux docker
    2
    0 Stimmen
    2 Beiträge
    159 Aufrufe
    FrankMF
    So, mal weiter damit beschäftigen. Also, durch meine ganze Testerei war doch ein Haufen Müll angefallen. dockeruser@opencloud:~/opencloud/deployments/examples/opencloud_full$ docker volume ls DRIVER VOLUME NAME local 0fcd6f237898477b251f3dacb6cd083996092b783f991f899b06d89befc41b1e local 1d8df3f5d41613ad93ed753ce2102a14738cf00e8e7d127ec79881660be291ab local 3b612ce20b207c226640d6b84c32c788cd0fad9f9157578c2310f4b3db63dd29 local 5dfdde733fefb9fdb805acec8338a860762e88cd0753f4bb4098a19fbcd4b6c3 local 6bd5659759fb99b0d0613175d2392ca268dbdb3bd0353b85ccdf9a6004e798c0 local 6f8881420aa0e7713ed5308e635fcb9382939b6570afbd1d776866a07f6d61f2 local 29f7d20edd9eda935041cea7af5aab0af748175d7df8f345288463753d2afa9a local 66ca6287706aac5013b458a109e7c143c4fb177670734fc7a0f68495b1c62fd4 local 74d304835ef51f91226cc22dbbd494d2ddc9a4d91badf88814cae24126efd04a local 0203eb654c1f28a60899ded4660fb101ea222a5f8c86a225d39f3e5da877f1c0 local 271c474feb2ed915afb8efa85e422461fcfdf8acd4097355841eadf33847b7ef local 569a8c34804afd5861299973bed023c0146f40c0dbda0d980b8651bbcadc7fc9 local 655b1f446b5db9749787d4be4445887dcb3d19906d4244d059a0f292a6cd5f01 local 843bb8d0d7845adab06e146c44b153b842d5a1a1d8eb3972bdee1d3cbcb7e815 local 987ee19b8639ad5fffabba276ceb1ca09af6ebc66efb007e561570589c9c53a8 local 1004f5b7b161a4fe37a07d7960740e5cd09b90d5744f1922fb3e41c1265f800a local 2043c77b57728106cbcca8b7e2d3ae2f07ddf4ca44ee21fca232526c95e07381 local 3685c81df1be0061352dfc5b0e6db8d8d9f9b0915a271f1ca53d2796a7876805 local 9581abcfb4fb42b2fabfabbc8139cc4659ca83d92a8b60041957565409293ef4 local 796650f1fa887ff0b153822b268a10aa3579f4f2ca3ce6855ff292e49b3bb6b8 local 426251107e3131a250b27b96e795355332127f19ccf1ec8252860aff5d0caec8 local bd43ceef38448db348cc34e7dc5c4fee9c834d8b6c5957b1e6cdb83cec7b0974 local d94e7ce6c0fb1f4f7b811f624b4526ea889f2f8b99d2aa1b21e79d00dfeb38d0 local e87a27c307a8be80839fae1c006273d57570bb99f60c78c95e86a1e9ea1a786c local f2b3e30406db730e2a341850243c115b6eb231f30f41f5353c7b2427de39af75 local opencloud_full_certs local opencloud_full_opencloud-apps local opencloud_full_opencloud-config local opencloud_full_opencloud-data Oje, das sieht ziemlich vermüllt aus. Dann mal ganz mutig alles löschen. Vorher alles gestoppt. docker compose down Volume löschen, nur ein Beispiel docker volume rm opencloud_full_opencloud-data Alles gelöscht. Dann mal ein Neustart docker compose up -d Jetzt sieht das schon viel besser aus. dockeruser@opencloud:~/opencloud/deployments/examples/opencloud_full$ docker volume ls DRIVER VOLUME NAME local 3737a8eab68ffdc08d6e41493346feeb2e06ef350a210213ab450775318e49f8 local opencloud_full_opencloud-apps Da ich neugierig bin, schauen wir mal rein. root@opencloud:~ ls -lha /var/lib/docker/volumes/3737a8eab68ffdc08d6e41493346feeb2e06ef350a210213ab450775318e49f8/_data/web/assets/apps/ total 8.0K drwxr-x--x 2 dockeruser dockeruser 4.0K May 19 18:25 . drwxr-x--x 3 dockeruser dockeruser 4.0K May 31 10:21 .. Vermutlich ein Speicher, wo die Web Apps was ablegen können. Der andere zeigt es dann klarer. root@opencloud-4gb-fsn1-2:~# ls -lha /var/lib/docker/volumes/opencloud_full_opencloud-apps/_data total 28K drwxr-x--x 7 dockeruser dockeruser 4.0K May 31 10:22 . drwx-----x 3 root root 4.0K May 31 10:21 .. drwxr-xr-x 2 root root 4.0K May 31 10:22 draw-io drwxr-xr-x 2 root root 4.0K May 31 10:21 external-sites drwxr-xr-x 3 root root 4.0K May 31 10:22 json-viewer drwxr-xr-x 2 root root 4.0K May 31 10:22 progress-bars drwxr-xr-x 3 root root 4.0K May 31 10:22 unzip Ok, das sollte mir erst mal reichen. Meine Installation lagert die certs ja aus, das habe ich im docker compose geändert. dockeruser@opencloud:~/opencloud/deployments/examples/opencloud_full$ ls -lha certs/ total 44K drwxr-xr-x 2 dockeruser dockeruser 4.0K May 30 05:49 . drwxr-xr-x 6 dockeruser dockeruser 4.0K May 31 10:38 .. -rw------- 1 dockeruser dockeruser 33K May 29 11:00 acme.json Im docker-compose.yml volumes: - ./certs:/certs # bind-mount acme.json Der Grund dafür ist, das ich das docker-compose nicht als root laufen haben möchte. Die Hauptdaten sind nach lokal ausgelagert. OC_CONFIG_DIR=/home/dockeruser/oc_data/config OC_DATA_DIR=/home/dockeruser/oc_data/data Somit sollte jetzt alles so passen und ich muss mal langsam mit der Spielerei aufhören
  • MongoDB - Erste Erfahrungen

    Linux mongodb linux ki-generiert
    2
    2
    0 Stimmen
    2 Beiträge
    275 Aufrufe
    FrankMF
    So frisch von der MongoDB Front und wieder viel gelernt, weil beim Üben macht man Fehler Oben war ja mongodump & mongorestore von der KI empfohlen. Hier das wie ich es gemacht habe. mongodump frank@redis-stack:~$ mongodump -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio -o mongodump/ 2024-04-06T09:29:25.174+0200 writing portfolio.stockList to mongodump/portfolio/stockList.bson 2024-04-06T09:29:25.175+0200 writing portfolio.users to mongodump/portfolio/users.bson 2024-04-06T09:29:25.175+0200 done dumping portfolio.stockList (8 documents) 2024-04-06T09:29:25.176+0200 writing portfolio.total_sum to mongodump/portfolio/total_sum.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.total_sum (1 document) 2024-04-06T09:29:25.177+0200 writing portfolio.old_total_sum to mongodump/portfolio/old_total_sum.bson 2024-04-06T09:29:25.177+0200 writing portfolio.stocks to mongodump/portfolio/stocks.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.users (4 documents) 2024-04-06T09:29:25.178+0200 writing portfolio.settings to mongodump/portfolio/settings.bson 2024-04-06T09:29:25.178+0200 done dumping portfolio.settings (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.old_total_sum (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.stocks (34 documents) mongorestore mongorestore -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio mongodump/meineDatenbank/ Hier wird die Datensicherung mongodump/meineDatenbank/ in die neue Datenbank portfolio transferiert. Grund für das Ganze? Mich hatte der Datenbank Name meineDatenbank gestört. Benutzerrechte Jetzt der Teil wo man schnell was falsch machen kann Ich hatte also die neue Datenbank, konnte sie aber nicht lesen. Fehlten halt die Rechte. Ich hatte dann so was hier gemacht. db.updateUser("frank", { roles: [ { role: "readWrite", db: "meineDatenbank" }, { role: "readWrite", db: "portfolio" }]}) Ging auch prima, kam ein ok zurück. Nun das Problem, ich hatte beim Einrichten, den User frank als admin benutzt. Durch den oben abgesetzten Befehl (frank ist ja admin), wurden die neuen Rechte gesetzt und die Rechte als Admin entzogen!! Das war jetzt nicht wirklich das was ich gebrauchen konnte. LOL Ich hatte jetzt keine Kontrolle mehr über die DB. Das war aber nicht so wirklich kompliziert, das wieder zu ändern. Die Authentication temporär abstellen. Also /etc/mongod.conf editieren und #security: security.authorization: enabled eben mal auskommentieren. Den Daemon neustarten und anmelden an der DB. mongosh --host 192.168.3.9 Danach neuen User anlegen db.createUser({ user: "<name>", pwd: "<password>", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] }) mongod.conf wieder ändern und neustarten. Danach hat man wieder eine DB mit Authentifizierung und einen neuen Admin. Ich bin diesmal, man lernt ja, anders vorgegangen. Es gibt nun einen Admin für die DB und einen User zum Benutzen der Datenbanken! So wie man es auch auf einem produktiven System auch machen würde. Wenn ich jetzt mal was an den Benutzerrechten des Users ändere, kann mir das mit dem Admin nicht mehr passieren. Hoffe ich
  • Intel ARC A580

    Linux linux intelarc debian
    4
    4
    0 Stimmen
    4 Beiträge
    634 Aufrufe
    FrankMF
    Zwei Monitore ausprobiert, einen 4K und einen Full-HD (HDMI). Lief einwandfrei, auch gemeinsam.
  • Virt-Manager

    Linux linux virt-manager
    1
    3
    0 Stimmen
    1 Beiträge
    124 Aufrufe
    Niemand hat geantwortet
  • NanoPi R2S - Firewall mit VLan und DHCP-Server

    Verschoben NanoPi R2S nanopir2s linux
    2
    2
    0 Stimmen
    2 Beiträge
    869 Aufrufe
    FrankMF
    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...
  • Kopia 0.7.x released

    Kopia kopia linux
    1
    0 Stimmen
    1 Beiträge
    254 Aufrufe
    Niemand hat geantwortet
  • Sidebar im Theme Quark bearbeiten

    Grav grav linux
    1
    0 Stimmen
    1 Beiträge
    636 Aufrufe
    Niemand hat geantwortet