Ich schaue mir gerade borg an. Bisher mache ich einige backups über ssh-tricks, habe aber auch mit rsync gespielt (rsnapshot anyone?).
Was nutzt ihr, und wie? Funktioniert das? Braucht ihr akut Lösungen?
Welche Backup-Lösungen (Linux) haben sich bewährt?
Back In Time arbeitet soweit ich es verstehe mit rsync und hardlinks. Bei hardlinks ist angeblich dass Problem, dass man irgendwann auf ein Limit stößt, ohne davor gewarnt zu werden. Ab da funktioniert dann die Deduplizierung nicht mehr bzw nicht mehr Platz-sparend. Hast du schon große Datenmengen via back-in-time gesichert, und zwar regelmäßig?
korrekt.
Definiere “groß” (wobei die Größe für das Hardlink-Limit ja irrelevant ist, da ist ja die Anzahl der Versionen relavant) 
Derzeit läuft (sofern mein Laptop an ist) der Backupjob stündlich; Quellgröße ist aktuell ca. 160GB. Auf der Backupplatte, mit ext4 formatiert, liegen gerade ca. 1,4TB. Das älteste Backup ist von 2010 (“intelligentes Löschen” ist aktiviert), es gibt derzeit 39 “Schnappschüsse”.
Bei ext4 ist laut https://en.wikipedia.org/wiki/Hard_link#Limitations_of_hard_links das Limit bei 65.000 Stück – da habe ich also die nächsten Jahre noch Ruhe, denke ich. 
1 Like
@felix, in dem Punkt kann ich mich @Simon anschließen. Mir gefällt Back in Time auch deshalb, weil es mich nicht auf regelmäßige Backups (stündlich/täglich/usw.) festlegt. Ich sichere in unregelmäßigen Abständen und schließe zu diesem Zweck eine externe Festplatte an, also nicht übers Netz.
Darüber hab ich sogar mal gebloggt: https://www.iromeister.de/umstieg-von-rdiff-backup-auf-back-in-time
1 Like
Hab gerade restic entdeckt, hier ein Vortrag des Entwicklers beim CCC Köln:
Edit: jetzt schaue ich mir den Vortrag überhaupt erst an & bin beeindruckt! 
Der Mann hat die UNIX-Philosophie verinnerlicht.
Coool, jetzt läuft gerade mein erstes Backup vom Synology-NAS auf den 1&1-Onlinespeicher (da haben wir durch unseren Vertrag gut 1 TB!!!). Die Installation gestaltet sich dank Go höchst simpel: einfach das passende Binary nach /usr/local/bin packen, chmod +x und los. Da man an den Onlinespeicher nur per WebDAV kommt, brauche ich dafür noch rclone, aber auch das ist ein einzelnes Go-Binary. 
Ich hoffe doch “client”-verschlüsselt. 
Du hast dir restic offensichtlich noch nicht näher angeschaut, das ist ein core feature.
Was den Speicherplatz angeht, der reicht auch bei uns nicht um alles zu sichern, aber die wichtigsten Sachen.
Weder das, noch habe ich die altne Posts gelesen. Habe nur
gelesen… 
Ich mache mir auch gerade Gedanken zum Thema Backup.
Als erstes sticht mir negativ ins Auge, dass die Lösungen alle pushen und nicht pullen.
Ein kompromittiertes Client-System hat dann im kompromittierten Zustand weiterhin Zugang zum Backup-Server. Das halte ich für keine sinnvolle Strategie.
Soweit mir bekannt, unterstützen Borg und restic beide nativ kein pull. Ich hab Frickellösungen gefunden um hier dennoch so zu arbeiten.
Wie handhabt ihr das?
Mich würde auch interessieren, wie ihr Mails sichert.
1 Like
Darin sehe ich deshalb kein ernst zu nehmendes Problem, weil ein Trojaner ja mit restic (oder Borg) umgehen können müsste. Im Prinzip kann er drauf zugreifen, aber ob er es wirklich tun wird? Das Risiko halte ich für vernachlässigbar.
naja… https://de.wikipedia.org/wiki/Security_through_obscurity
bei einem automatisierten restic habe ich scripte mit passwörtern oder ich hab ssh keys oder ähnliches im system…
wohin schiebt ihr so eure backups?
(also über die hier im Thread bereits erwähnten Lösungen hinaus)
Dass ich das noch erleben muss - mir wird Security by obscurity vorgeworfen… Prinzipiell ist es das zwar, aber inzwischen bin ich so pragmatisch geworden, dass ich nur entsprechenden Aufwand treibe, je nachdem was für einen Angriff ich für realistisch halte. Unter dem Gesichtspunkt ist Security by obscurity immer noch besser als gar keine Security, denn auch um diese zu überwinden ist kriminelle Energie nötig.
Das Szenario, für das ich vorsorge, ist, dass eine Ransomware unser NAS per Netzwerkfreigabe verschlüsselt. Ich halte es für sehr unwahrscheinlich, dass so eine (automatisierte) Ransomware nun ausgerechnet Routinen zum Löschen eines Restic-Backups eingebaut hat.
Sollte tatsächlich ein menschlicher Hacker eigenhändig in unser Netz eindringen inklusive SSH-Zugang zu unserem NAS, dann hätten wir natürlich verloren. Das sehe ich allerdings nicht, denn selbst wenn sich die Emotet-Leute, wie sie es ja machen, gründlich in unserem Netzwerk umschauen würden, kämen sie aller Voraussicht nach dem Schluss, dass bei uns nicht genug zu holen ist, als dass sich der Aufwand für sie lohnen würde.
Jedenfalls @Dennis, wenn du da ernsthafte Bedenken hast, dann äußere diese doch im Restic-Forum, dort wirst du voraussichtlich eine kompetente Antwort bekommen.
P.S.: Für den Fall, dass tatsächlich das restic-Backup gelöscht und die externe Backup-Festplatte genau in der einen Nacht verschlüsselt wird, in der sie pro Woche am NAS hängt, habe ich vor, eine 2. externe Backup-Platte anzuschaffen & diese dann immer im Wechsel dran zu hängen.
Einatmen Ausatmen.
ssh-Schlüssel lassen sich via .ssh/authorized_keys übrigends wunderbar in ihrer Nutzbarkeit beschränken, so dass mit ihnen kein/kaum/schwerlich Schindluder getrieben werden kann (nochmal oben drauf neben der ganzen Nutzer-Permission-Schiene).
Damit lassen sich einfache tar-backups gut und sicher via pull realisieren: https://github.com/ecovillage/sometimes macht das so (ist aber geschätzte 20 Stunden vor Entwicklungsstand „gut nutzbar“).
1 Like
Hey… wollte dich nicht persönlich angreifen…
Löschen lässt sich ja auf Restic-Server-Seitig auch generell unterbinden. Das ist ja das kleinere Problem. Den SSH Schlüssel ausschließlich für den einen NAS zugang zu setzen, ist ja auch schonmal eine gute Einschränkung.
Dem Restic das Lesen und damit den zugriff auf alte Daten zu verbieten, dürfte aber unmöglich sein. Ich muss mir das nochmal in Ruhe anschauen.
Mir geht es um wirklich sensible Daten. Daher kann das Konzept gar nicht genug Alu-Hütte verpasst bekommen =)
Ich bleibe dran…
Alles klar, dann haben wir wie vermutet einfach unterschiedliche Anforderungen.
Privat: Wie beschrieben BackInTime. Auch push. Wenn sich mein Ubuntu Ransomware einfängt, dann habe ich Pech.
Gemeinschaft: Win Clients sichern Daten auf NAS (Samba). NAS macht via pull versioniertes Backup auf 2. NAS. Wenn sich der Client Ransomware einfängt, kann er die Dateien auf dem NAS verschlüsseln, die dann auf dem 2. NAS verschlüsselt gebackupt werden. Die alten unverschlüsselten Dateien auf dem 2. NAS sind jedoch für den Client nicht zugreifbar. Wenn sich das NAS Ransomware einfängt, dann kann es vermutlich die Dateien auf dem 2. NAS verschlüsseln, dann haben wir Pech gehabt.
Nur Client. Extern gehostete IMAP Konten: Gar nicht. Lokal liegende POP3 Konten: Das gesamte Thunderbirdprofil.
Privat: externe HDD (die aktuell dauerhaft am Laptop hängt). Nach Weihnachten plane ich ein Konstrukt aus 2 NAS in getrennten Gebäuden.
Gemeinschaft: 1. NAS dient als zentraler Speicher, Backup auf 2. NAS in getrenntem Gebäude.
3 Like