Guten Abend, ich möchte gewisse Orner von meinem V-server auf meinen Pc bzw auf Googledrive sichern. Welche Tools gibt es dazu? Es sollte relativ automatisch gehen;) Lg
Ok ftp muss halt einen Ftpserver aufsetzen. Oder kann man direkt vom vserver auf googledrive? Lg
hab tartarus im einsatz, das schiebt mit per ftps oder sftp(?), jedenfalls verschlüsselt, regelmäßig ein backup auf meinen filezilla ftp server zu hause.
:
Bearbeitet durch User
Schau dir Mal duplicati an. Ansonsten wenn's der eigene PC ist auch rsync. Mach aber am Besten was automatisches und teste ob wirklich alles da ist. Auch mehrere Generationen aufzubewahren ist sinnvoll, manchen Mist merkt man unter Umständen erst nach der 3. Sicherung oder so.
Naja... bei FTP wird das Passwort zum Login unverschlüsselt übertragen... Wie wäre es mit SCP oder RSYNC über SSH?
pegel schrieb: > Wenn auch ftp läuft, einfach rüber ziehen. Wer heute noch FTP empfiehlt, sollte anderen keine Tipps geben. Echt jetzt.
Lucas N. schrieb: > bei sftp auch? SFTP nutzt das FTP-Protokoll über eine verschlüsselte SSH-Verbindung, über die natürlich auch die Authentifizierung vorgenommen wird.
wohl, wohl. sftp? ftps? dann sollte aber das backuparchiv verschlüsselt sein. nur weil es keine REST API unterstützt, muss es nicht schlecht sein. wenn es für die anforderung passt, warum nicht.
Sven schrieb: > Schau dir Mal duplicati an. Gute Empfehlung, entweder das [1] oder duplicity [2] und duply [3] -- bitte alles über SFTP. > Ansonsten wenn's der eigene PC ist auch rsync. Rsync über SSH ist eine gute Idee, ansonsten könnten aber auch SCM-Systeme wie Subversion, Mercurial oder Git in Frage kommen. > Mach aber am Besten was automatisches und teste ob wirklich alles > da ist. Unbedingt! Aber nach meiner Erfahrung kommen Probleme immer erst dann vor, wenn man einen echten Restore probiert. Denn beim Testen, "ob wirklich alles da ist", hat man ja immer nur das im Kopf, was man gerade in seine Backup-Listen eingetragen hat... Die "unknown unknowns", die man dabei vergessen hat, ... nun, die sind dann eben weg. Auch beliebt: das defekte Medium (Tape, Disk, ...), auf das man seit Jahren ohne Fehlermeldung seine Backups schreibt, aber im Not- bzw. Restorefall nicht mehr gelesen werden kann... Been there, done that. Deswegen: unbedingt_ und _regelmäßig einen Restore auf einem nackigen System versuchen, idealerweise auf einem, das der Produktionsumgebung so nahe wie irgend möglich kommt. Wer sein Restore nicht regelmäßig testet, hat kein Backup. Es gilt: kein Backup, kein Mitleid. ;-) > Auch mehrere Generationen aufzubewahren ist sinnvoll, manchen > Mist merkt man unter Umständen erst nach der 3. Sicherung oder so. Auch das ist absolut korrekt! [1] https://www.duplicati.com/ [2] http://duplicity.nongnu.org/ [3] http://duply.net/
Sheeva P. schrieb: > SFTP nutzt das FTP-Protokoll über eine verschlüsselte SSH-Verbindung, > über die natürlich auch die Authentifizierung vorgenommen wird. SFTP erlaubt zwar Fileoperationen über SSH, verwendet dazu aber nicht das FTP Protokoll. Verschlüsseltes FTP gibts als FTPS, was aber mit SSH nichts zu tun hat.
Lucas N. schrieb: > wohl, wohl. sftp? ftps? dann sollte aber das backuparchiv verschlüsselt > sein. nur weil es keine REST API unterstützt, muss es nicht schlecht > sein. wenn es für die anforderung passt, warum nicht. Ach, was soll ich da sagen... SFTP ist FTP über SSH, und SSH ist seit Jahren eines der sichersten und komfortabelsten Transportprotokolle auf dem Markt. SSH erzwingt dabei normalerweise auch eine sichere Authentifizierung -- und kann neben verschiedenen Authentifizierungsmethoden (Paßwort, Zertifikate) nicht nur Dateitransfers über SFTP und SCP, sondern auch Shellzugriffe und PTP-Tunneling / Portforwarding über SSH. FTPS ist FTP über TLS (früher SSL), das ist verschlüsselungstechnisch zwar ähnlich sicher wie SSH, hat in den letzten Jahren aber wesentlich -- nein: SEHR wesentlich -- mehr Sicherheitsprobleme gehabt als SSH. Und wenn man es nicht entsprechend (und relativ aufwändig) aufsetzt, kümmert sich TLS leider auch nicht um eine sichere Authentifizierung... TLS/SSL lohnt sich eher bei großen Umgebungen mit vielen Nutzern, einer automatisierten Verwaltung und Verteilung von Zertifikaten, einer eigenen Certification Authority und ein paar anderen Nebenbedingungen. Um das Archiv zu verschlüsseln, gibt es eine Vielzahl anderer Lösungen, von einer internen Festplattenverschlüsselung mit entsprechender Hardware, meist mit AES128- oder AES256-Verschlüsselung, über PGP/GPG-verschlüsselte Archive bis hin zu betriebssystemseitigen Methoden wie LUKS oder Bitlocker. Was die REST Api hier zu suchen hat, ist mir schleierhaft. Das ist doch nur eine Methode, wie APIs gestaltet werden können, und hat mit Dateitransfers, Verschlüsselung, Authentifizierung oder Autorisierung wenig zu tun.
A. K. schrieb: > SFTP erlaubt zwar Fileoperationen über SSH, verwendet dazu aber nicht > das FTP Protokoll. Darüber könnte man wunderbar streiten... Fakt ist, daß SFTP die üblichen FTP-Befehle wie ls, cd, get, put et al. unterstützt, und insofern aus Sicht des Benutzers weitestgehend wie FTP aussieht. Richtig ist aber auch, daß das auf der Netzwerkebene etwas anders aussieht. Für Macromedia war es seinerzeit ein Kinderspiel, den FTP-Client in ihrem Dreamweaver um SFTP zu erweitern: einfach ein anderes Binary aufrufen, das Nutzerprotokoll war im Prinzip dasselbe. ;-) > Verschlüsseltes FTP gibts als FTPS, was aber mit SSH > nichts zu tun hat. Natürlich, siehe meinen Beitrag von 22:46 Uhr.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.