{"id":12398,"date":"2025-09-09T15:17:07","date_gmt":"2025-09-09T13:17:07","guid":{"rendered":"https:\/\/webhosting.de\/backup-rsync-automatisieren-datensicherheit-hosting-protect\/"},"modified":"2025-09-09T15:17:07","modified_gmt":"2025-09-09T13:17:07","slug":"back-up-rsync-automatiseren-gegevensbeveiliging-hosting-beschermen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/backup-rsync-automatisieren-datensicherheit-hosting-protect\/","title":{"rendered":"Back-up automatiseren via rsync - gegevensbeveiliging voor beheerders"},"content":{"rendered":"<p>Ich automatisiere mein <strong>rsync backup<\/strong>, um Ausf\u00e4lle zu vermeiden und Wiederherstellungen planbar zu halten. Mit klaren <strong>Cron-Jobs<\/strong>, SSH-Transport und inkrementellen L\u00e4ufen sichere ich Webserver, Datenbanken und Konfigurationen effizient.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>Automatisierung<\/strong>: Zeitgesteuerte Jobs reduzieren Fehler und Aufwand.<\/li>\n  <li><strong>Effizienz<\/strong>: Delta-Transfer spart Bandbreite und Speicher.<\/li>\n  <li><strong>Sicherheit<\/strong>: SSH, Schl\u00fcsselmanagement und Offsite-Ziele.<\/li>\n  <li><strong>Strategie<\/strong>: GFS-Aufbewahrung und klare RPO\/RTO-Ziele.<\/li>\n  <li><strong>Transparenz<\/strong>: Logging, Monitoring und Restore-Tests.<\/li>\n<\/ul>\n\n<h2>Warum ich Backups automatisiere<\/h2>\n\n<p>Ich sichere produktive Systeme konsequent, weil ein einzelner Ausfall ganze Projekte stoppen kann und ich <strong>Verf\u00fcgbarkeit<\/strong> garantieren will. Ein geplanter Backup-Lauf um 02:00 Uhr ersetzt fehleranf\u00e4llige Handarbeit und sorgt f\u00fcr saubere Datenst\u00e4nde. Ich definiere f\u00fcr jeden Server klare Ziele: Wie viel Datenverlust ist akzeptabel (RPO) und wie schnell muss die Wiederherstellung erfolgen (RTO). Diese Ziele beeinflussen Zeitplan, Speicherziel und Optionen, damit ich den Betrieb verl\u00e4sslich absichere. Gerade bei Webservern reduziere ich so Risiken durch Hardwaredefekte, Ransomware oder versehentliches L\u00f6schen auf ein kalkulierbares Minimum.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/09\/rsync-backup-serverraum-9472.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>rsync kurz erkl\u00e4rt: Funktionsweise und St\u00e4rken<\/h2>\n\n<p>rsync \u00fcbertr\u00e4gt nur \u00c4nderungen, nutzt einen effizienten <strong>Delta-Transfer<\/strong> und vermeidet unn\u00f6tige Kopien. Dadurch sinken Laufzeiten, Netzlast und IO auf dem Zielsystem deutlich. Ich arbeite im Archivmodus (-a), damit Rechte, Zeiten, Besitzer und Symlinks konsistent bleiben. Mit &#8211;delete halte ich Spiegel aktuell, achte aber auf den Einsatzzweck und kombiniere es bei Versionierung mit separaten Verzeichnissen. F\u00fcr Transport setze ich auf SSH, bei lokalen Jobs auf direkte Pfade, und erg\u00e4nze bei Bedarf Komprimierung (-z) sowie Bandbreitenlimit (&#8211;bwlimit).<\/p>\n\n<h2>Automatisierung mit Cron: Schritt f\u00fcr Schritt<\/h2>\n\n<p>Ich starte mit einem einfachen Skript, denn klare <strong>Baselines<\/strong> lassen sich sp\u00e4ter ausbauen. Zuerst installiere ich rsync, falls es fehlt, und lege ein sicheres Arbeitsverzeichnis f\u00fcr Logs und Status an. Danach schreibe ich ein Skript mit Quellen, Ziel und sinnvollen Optionen inklusive Ausschl\u00fcssen. Der Cronjob l\u00e4uft t\u00e4glich oder st\u00fcndlich je nach RPO und schreibt Logdateien f\u00fcr Auswertung und Alarmierung. Ein Dry-Run (-n) vor dem ersten produktiven Lauf verhindert unerw\u00fcnschte L\u00f6schungen.<\/p>\n\n<pre><code># Installation (Debian\/Ubuntu)\nsudo apt-get install rsync\n\n# Minimaler Lauf lokal\nrsync -a \/data\/www\/ \/backup\/www\/\n\n# Remote-Spiegel \u00fcber SSH mit L\u00f6schungen\nrsync -a --delete -e \"ssh -i \/root\/.ssh\/backup_key\" \/data\/www\/ backup@backuphost:\/srv\/backups\/www\/\n\n# Cron: t\u00e4glich um 02:00 Uhr\n0 2 * * * \/usr\/local\/bin\/rsync-backup.sh &gt;&gt; \/var\/log\/rsync-backup.log 2&gt;&amp;1\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/09\/rsync_backup_meeting_automatisierung_9347.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>SSH-Backups sicher aufsetzen<\/h2>\n\n<p>Ich nutze SSH-Schl\u00fcssel mit begrenzten Rechten, weil <strong>Schl\u00fcsselmanagement<\/strong> die Angriffsfl\u00e4che verkleinert. Auf dem Zielsystem begrenze ich Befehle per authorized_keys und nutze einen getrennten Backup-User. Fail2ban, Firewall-Regeln und restriktive SSH-Optionen (z. B. PasswordAuthentication no) erh\u00f6hen die Sicherheit. Ich hinterlege den Host-Key fest, damit Man-in-the-Middle keine Chance hat. Wer einen strukturierten Start sucht, findet praxiserprobte Ideen unter <a href=\"https:\/\/webhosting.de\/backups-automatisieren-tipps-tools-hosting-strategie-expert\/\">Backups automatisieren<\/a>.<\/p>\n\n<h2>Pull statt Push: Sicherheitsvorteile in der Praxis<\/h2>\n\n<p>Wo m\u00f6glich lasse ich den <strong>Backup-Server pullen<\/strong> statt den Produktivserver pushen. So bleiben Produktionssysteme ohne ausgehende Schl\u00fcssel, und ein kompromittierter Webserver kann keine Offsite-Backups l\u00f6schen. Auf dem Ziel begrenze ich den Schl\u00fcssel in der authorized_keys mit restriktiven Optionen und einer Zwangscommand.<\/p>\n\n<pre><code># Beispiel authorized_keys auf dem Backupziel\nfrom=\"10.0.0.10\",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding,command=\"\/usr\/local\/bin\/rsync-serve-backups\"\n\/home\/backup\/.ssh\/authorized_keys\n<\/code><\/pre>\n\n<p>Das aufgerufene Skript erlaubt ausschlie\u00dflich rsync-Server-Aufrufe und setzt Pfadgrenzen. So erreiche ich ein <strong>Prinzip minimaler Rechte<\/strong>, ohne die Bedienung zu verkomplizieren.<\/p>\n\n<h2>Versionierung und Aufbewahrung mit Hardlinks<\/h2>\n\n<p>F\u00fcr mehrere St\u00e4nde baue ich mit &#8211;link-dest Tages-, Wochen- und Monatsordner, weil <strong>Hardlinks<\/strong> Speicher sparen und Wiederherstellungen vereinfachen. Jede Generation verweist auf identische, unver\u00e4nderte Dateien der vorherigen Sicherung, neue oder ge\u00e4nderte Dateien landen physisch im neuen Ordner. So erreiche ich viele Wiederherstellungspunkte bei moderatem Speicherbedarf. Ich entferne alte Generationen mit einem einfachen Rotationsskript, ohne Datenkonsistenz zu riskieren. Ein fixer Zeitplan (z. B. 7 Tage, 4 Wochen, 6 Monate) h\u00e4lt Speicherplanung klar und transparent.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/09\/rsync-backup-admin-sicherheit-7493.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ressourcen steuern: Bandbreite, CPU und I\/O<\/h2>\n\n<p>Ich begrenze den Datendurchsatz mit &#8211;bwlimit, damit <strong>Produktivlast<\/strong> stabil bleibt und Nutzer keine Einbu\u00dfen sp\u00fcren. Mit nice und ionice reduziere ich Priorit\u00e4ten der Backup-Prozesse. Auf langsamen Netzen schalte ich Komprimierung (-z) zu, auf schnellen lokalen Medien lasse ich sie weg. Bei gro\u00dfen Dateien w\u00e4hle ich &#8211;partial, um abgebrochene \u00dcbertragungen fortsetzen zu k\u00f6nnen. F\u00fcr lokale Spiegel nutze ich oft &#8211;whole-file, weil der Delta-Algorithmus dort keine Vorteile bringt.<\/p>\n\n<h2>Konsistente Datenst\u00e4nde: Snapshots und Datenbanken<\/h2>\n\n<p>Um konsistente Backups trotz offener Dateien zu erhalten, nutze ich <strong>Snapshots<\/strong> oder Applikations-Hooks. Dateisysteme wie LVM, ZFS oder Btrfs erlauben schnelle Snapshots, die ich als Quelle f\u00fcr rsync verwende. So friere ich den Datenstand logisch ein, ohne Dienste lange zu blockieren.<\/p>\n\n<pre><code># Beispiel: LVM-Snapshot als konsistente Quelle\nlvcreate -L 10G -s -n data_snap \/dev\/vg0\/data\nmount \/dev\/vg0\/data_snap \/mnt\/data_snap\nrsync -a --delete \/mnt\/data_snap\/www\/ backup@host:\/srv\/backups\/www\/\numount \/mnt\/data_snap\nlvremove -f \/dev\/vg0\/data_snap\n<\/code><\/pre>\n\n<p>F\u00fcr <strong>Datenbanken<\/strong> trenne ich Logik und Files. MySQL\/MariaDB sichere ich via Dump oder Percona\/Xtra-L\u00f6sungen, PostgreSQL mit pg_dump oder basebackups. Wichtig ist die Reihenfolge: erst konsistenten Dump erzeugen, dann den Dump-Pfad per rsync \u00fcbertragen. So verhindere ich halbgeschriebene Dateien im Backup.<\/p>\n\n<h2>Typische Fehlerquellen und wie ich sie vermeide<\/h2>\n\n<p>Der h\u00e4ufigste Stolperstein ist der Schr\u00e4gstrich am Ende eines Pfads, daher pr\u00fcfe ich <strong>Pfadangaben<\/strong> doppelt: \/src\/ vs. \/src. Ausschl\u00fcsse teste ich mit &#8211;dry-run und &#8211;itemize-changes, um die Wirkung zu sehen. Ich zitiere Muster mit Leerzeichen korrekt und halte die exclude-Datei im Repository. Vor &#8211;delete kontrolliere ich Mounts, weil ein nicht gemountetes Ziel zu unerw\u00fcnschtem L\u00f6schen f\u00fchren kann. Schlie\u00dflich protokolliere ich R\u00fcckgabecodes und aktiviere Alarme, damit ich Fehler sofort sehe.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/09\/rsync_backup_admins_nacht_2843.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Backup-Strategie: GFS und Recovery-Ziele<\/h2>\n\n<p>Ich lege zuerst RPO\/RTO fest, weil klare <strong>Ziele<\/strong> jede Entscheidung \u00fcber Frequenz, Lagerort und Retention leiten. Ein g\u00e4ngiges Schema ist GFS: t\u00e4glich differenziell, w\u00f6chentlich voll oder via Hardlinks zusammengef\u00fchrt, monatlich langfristig. Compliance-Anforderungen beeinflussen die Aufbewahrungsdauer, daher trenne ich kurzlebige Betriebsdaten von langfristigen Archiven. F\u00fcr kritische Systeme plane ich Offsite-Backups zus\u00e4tzlich zu lokalen Kopien ein. Diese Kombination sch\u00fctzt vor Standortausf\u00e4llen und erm\u00f6glicht schnelle wie auch entfernte Wiederherstellungen.<\/p>\n\n<h2>Cron oder systemd-timer: Zuverl\u00e4ssig planen<\/h2>\n\n<p>Cron ist simpel und robust. F\u00fcr Hosts, die gelegentlich schlafen oder neu starten, nutze ich zus\u00e4tzlich <strong>systemd-timer<\/strong> mit Abh\u00e4ngigkeiten und Missed-Run-Handling. Damit stelle ich sicher, dass nach einem Reboot kein Lauf ausf\u00e4llt und die Reihenfolge (z. B. nach Netzwerkwiederherstellung) stimmt.<\/p>\n\n<pre><code># \/etc\/systemd\/system\/rsync-backup.service\n[Unit]\nDescription=Rsync Backup\nAfter=network-online.target\nWants=network-online.target\n\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/bin\/rsync-backup.sh\nNice=10\nIOSchedulingClass=best-effort\nIOSchedulingPriority=7\n\n# \/etc\/systemd\/system\/rsync-backup.timer\n[Unit]\nDescription=T\u00e4glicher Rsync-Backup-Timer\n\n[Timer]\nOnCalendar=02:00\nPersistent=true\n\n[Install]\nWantedBy=timers.target\n<\/code><\/pre>\n\n<h2>Tabelle: Wichtige rsync-Optionen im Alltag<\/h2>\n\n<p>Ich nutze wenige, aber wirkungsvolle <strong>Optionen<\/strong>, die ich pro Job dokumentiere und im Repo versioniere. Der Archivmodus bildet die Basis und reduziert Konfigurationsfehler. Mit &#8211;delete halte ich Spiegel sauber, setze es aber nur mit korrekter Zielpr\u00fcfung ein. F\u00fcr Versionierung kombiniere ich &#8211;link-dest mit einem Rotationsplan. Die folgende Tabelle zeigt die wichtigsten Schalter und ihren Einsatz.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Option<\/th>\n      <th>Zweck<\/th>\n      <th>Hinweis<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>-a<\/td>\n      <td>Archivmodus<\/td>\n      <td>\u00dcbernimmt Rechte, Zeiten, Besitzer f\u00fcr <strong>Konsistenz<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>-z<\/td>\n      <td>Komprimierung<\/td>\n      <td>Bei WAN n\u00fctzlich, lokal oft weglassen<\/td>\n    <\/tr>\n    <tr>\n      <td>&#8211;delete<\/td>\n      <td>Entfernt entfernte Altdateien<\/td>\n      <td>Nur bei Spiegeln nutzen, vorher Dry-Run<\/td>\n    <\/tr>\n    <tr>\n      <td>&#8211;bwlimit=KBPS<\/td>\n      <td>Bandbreite drosseln<\/td>\n      <td>Sch\u00fctzt <strong>Produktivsysteme<\/strong> vor Lastspitzen<\/td>\n    <\/tr>\n    <tr>\n      <td>&#8211;link-dest=DIR<\/td>\n      <td>Versionierung via Hardlinks<\/td>\n      <td>Sparsame Generationen mit getrennten Ordnern<\/td>\n    <\/tr>\n    <tr>\n      <td>-e &#8222;ssh &#8230;&#8220;<\/td>\n      <td>Sicherer Transport<\/td>\n      <td>Schl\u00fcssel, Host-Keys, restriktive User<\/td>\n    <\/tr>\n    <tr>\n      <td>-n \/ &#8211;dry-run<\/td>\n      <td>Testlauf ohne \u00c4nderungen<\/td>\n      <td>Zeigt geplante Aktionen vorab<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/09\/rsync_backup_sicherheit_8421.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wiederherstellung testen: Restore-\u00dcbungen<\/h2>\n\n<p>Ich teste regelm\u00e4\u00dfig die R\u00fccksicherung, weil ein Backup ohne Restore nur <strong>Schein<\/strong> ist. F\u00fcr Proben stelle ich einzelne Dateien sowie ganze Webroots in Staging-Umgebungen wieder her. Datenbanken sichere ich getrennt per Dump und spiele sie testweise ein, um Konsistenzen zu pr\u00fcfen. Checksummen helfen mir, Integrit\u00e4t zu best\u00e4tigen und stille Bitfehler zu erkennen. Nach jedem Test passe ich Dokumentation, Skripte und Playbooks an, damit der n\u00e4chste Ernstfall schneller abl\u00e4uft.<\/p>\n\n<h2>Bare-Metal und System-Backups: Besonderheiten<\/h2>\n\n<p>F\u00fcr System- oder Bare-Metal-Backups erweitere ich die rsync-Optionen, um <strong>ACLs, xattrs und Hardlinks<\/strong> mitzunehmen. Auf Linux hat sich -aAXH und &#8211;numeric-ids bew\u00e4hrt. Ich schlie\u00dfe Pseudo-Dateisysteme wie \/proc, \/sys, \/run, \/dev\/pts aus und sichere Boot- und Konfigurationsdateien separat dokumentiert.<\/p>\n\n<pre><code># Systemnahe Sicherung (Beispiel)\nrsync -aAXH --numeric-ids \\\n  --exclude={\"\/proc\/*\",\"\/sys\/*\",\"\/run\/*\",\"\/dev\/pts\/*\",\"\/tmp\/*\"} \\\n  \/ root@backup:\/srv\/backups\/hostA\/current\/\n\n# Wiederherstellung (vereinfacht, von Live-Medium)\nrsync -aAXH --numeric-ids \/srv\/backups\/hostA\/current\/ \/mnt\/target\/\nchroot \/mnt\/target update-initramfs -u\ngrub-install \/dev\/sda &amp;&amp; update-grub\n<\/code><\/pre>\n\n<p>Ich plane f\u00fcr solche Restores mehr Zeit ein, dokumentiere die Reihenfolge und halte Bootloader-Schritte parat. Das reduziert Stress im Notfall erheblich.<\/p>\n\n<h2>Plesk-Integration: Panel-Jobs schlau kombinieren<\/h2>\n\n<p>Ich kombiniere Plesk-Aufgaben mit rsync, damit <strong>Panel-Backups<\/strong> und Offsite-Kopien zusammenspielen. Post-Backup-Hooks \u00fcbertragen frische Sicherungen sofort auf einen externen Speicher. Zeitpl\u00e4ne stimmen mit Wartungsfenstern \u00fcberein, damit Deployments und Backups sich nicht behindern. Logrotation im Panel und auf dem Zielsystem verhindert wachsende Logverzeichnisse. Eine gute Einstiegshilfe liefert <a href=\"https:\/\/webhosting.de\/automatisierte-backups-plesk-best-practices-datensicherheit\/\">Plesk Best Practices<\/a> mit Fokus auf wiederholbare Abl\u00e4ufe.<\/p>\n\n<h2>cPanel-Integration: Homedirs und Datenbanken<\/h2>\n\n<p>Ich ziehe cPanel-Backups anschlie\u00dfend via rsync auf einen externen Host, damit <strong>Offsite-Schutz<\/strong> ohne Zusatzlast bleibt. Die Verzeichnisstruktur erleichtert selektive Wiederherstellungen einzelner Accounts. F\u00fcr gro\u00dfe Reseller-Setups plane ich differenzielle L\u00e4ufe \u00fcber die Nacht und volle St\u00e4nde am Wochenende. In Kombination mit Quotas und Rotationen halte ich Speicherbedarf transparent. Eine praktische Erg\u00e4nzung sind die Hinweise zu <a href=\"https:\/\/webhosting.de\/automatisierte-backups-cpanel-websitesicherheit\/\">cPanel-Backups<\/a> f\u00fcr einen soliden Betriebsalltag.<\/p>\n\n<h2>Skalierung und Struktur: Viele Jobs sauber managen<\/h2>\n\n<p>Wachsen Umgebungen, strukturiere ich Quellen und Excludes zentral. Mit <strong>&#8211;files-from<\/strong> \u00fcbergebe ich Listen, die ich im Repo versioniere. So \u00e4ndere ich S\u00e4tze ohne Skripte anzufassen und halte Standorte konsistent.<\/p>\n\n<pre><code># files-from-Beispiel\n\/etc\/backup\/www.list\n\/data\/www\/\n\/etc\/nginx\/\n\/var\/www\/html\/\n\nrsync -a --delete --files-from=\/etc\/backup\/www.list \/ backup@host:\/srv\/backups\/www\/\n<\/code><\/pre>\n\n<p>Ich vermeide \u00dcberlappungen, indem ich Pfadverantwortung klar trenne (z. B. Webroot getrennt von Logs). F\u00fcr gro\u00dfe Sets plane ich Parallelit\u00e4t bewusst \u2013 lieber wenige, gut getimte Jobs statt Dutzende konkurrierende Prozesse.<\/p>\n\n<h2>Robustheit im Betrieb: Locking, Retries, Timeouts<\/h2>\n\n<p>Um \u00dcberschneidungen zu vermeiden, nutze ich <strong>flock<\/strong> oder Lockfiles. Netzwerkprobleme fange ich mit Retries und &#8211;partial ab. Mit &#8211;timeout beende ich h\u00e4ngende Verbindungen sauber und alarmiere.<\/p>\n\n<pre><code># \/usr\/local\/bin\/rsync-backup.sh (Auszug)\n#!\/usr\/bin\/env bash\nset -euo pipefail\n\nexec 9&gt; \/var\/lock\/rsync-backup.lock\nflock -n 9 || { echo \"Backup l\u00e4uft bereits\"; exit 1; }\n\nLOG=\/var\/log\/rsync-backup.log\nSRC=\/data\/www\/\nDST=backup@backuphost:\/srv\/backups\/www\/\n\nfor i in {1..3}; do\n  if rsync -a --delete --partial --timeout=600 -e \"ssh -i \/root\/.ssh\/backup_key\" \"$SRC\" \"$DST\"; then\n    echo \"OK\"; exit 0\n  fi\n  echo \"Retry $i\" | tee -a \"$LOG\"\n  sleep 60\ndone\necho \"Fehler nach Retries\" &gt;&gt; \"$LOG\"; exit 1\n<\/code><\/pre>\n\n<h2>Optionen f\u00fcr Spezialf\u00e4lle: ACLs, xattrs, Sparse und Atomarit\u00e4t<\/h2>\n\n<p>Je nach Datenart passe ich rsync an. F\u00fcr Web- und Systempfade sichere ich <strong>ACLs und xattrs<\/strong> mit -A -X. Gro\u00dfe, sp\u00e4rlich belegte Dateien (VM-Images, Datenbanken) profitieren von <strong>&#8211;sparse<\/strong>. Mit <strong>&#8211;delay-updates<\/strong> und <strong>&#8211;delete-delay<\/strong> minimiere ich Zwischenzust\u00e4nde und erreiche quasi-atomare Updates auf dem Ziel. Bei heiklen Daten vermeide ich &#8211;inplace, damit defekte Transfers nicht die letzte gute Kopie \u00fcberschreiben.<\/p>\n\n<pre><code># Beispiel f\u00fcr umfangreiche Metadaten\nrsync -aAXH --sparse --delete-delay --delay-updates SRC\/ DST\/\n<\/code><\/pre>\n\n<p>Wenn ich absolut atomare Verzeichnisse brauche (z. B. f\u00fcr Staging), synchronisiere ich in ein tempor\u00e4res Ziel und <strong>renne<\/strong> anschlie\u00dfend per mv auf das Live-Verzeichnis um.<\/p>\n\n<h2>Sichere L\u00f6schgrenzen und Plausibilit\u00e4tschecks<\/h2>\n\n<p>Um Katastrophen durch Fehlkonfiguration zu verhindern, setze ich <strong>&#8211;max-delete<\/strong> als Guardrail. Au\u00dferdem pr\u00fcfe ich vor dem Lauf Mounts, freien Speicher und Inodes. Ich lasse mir die letzte erfolgreiche Sicherung protokollieren und warne bei Ausrei\u00dfern (extreme L\u00f6sch- oder \u00c4nderungsraten).<\/p>\n\n<pre><code># Schutz vor Massenl\u00f6schung\nrsync -a --delete --max-delete=5000 SRC\/ DST\/\n\n# Plausibilit\u00e4tscheck (einfach)\ndf -h \/srv\/backups\ndf -i \/srv\/backups\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/09\/rsync-backup-server-8492.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst: So gehe ich vor<\/h2>\n\n<p>Ich definiere zuerst RPO\/RTO, weil klare <strong>Priorit\u00e4ten<\/strong> jede technische Wahl leiten. Danach schreibe ich ein schlankes Skript, teste mit &#8211;dry-run und logge jede Ausf\u00fchrung. Mit SSH-Schl\u00fcsseln, Bandbreitenlimit und Versionierung sichere ich effizient und nachvollziehbar. Offsite-Ziele erg\u00e4nzen lokale Kopien, und regelm\u00e4\u00dfige Restore-\u00dcbungen best\u00e4tigen die Tauglichkeit. So bleibt mein rsync backup verl\u00e4sslich, schnell und jederzeit einsatzbereit.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe u uw rsync-back-up kunt automatiseren om betrouwbare gegevensbeveiliging voor servers en webprojecten te garanderen.<\/p>","protected":false},"author":1,"featured_media":12391,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-12398","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2680","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":["webhostinglogo.png"],"litespeed_vpi_list_mobile":["webhostinglogo.png"],"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"rsync backup","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"12391","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/12398","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=12398"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/12398\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/12391"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=12398"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=12398"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=12398"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}