In my opinion mixing synchronisation and backup is a bad thing, as they are two different things. You could fire an external application on event or periodic (e.g rsync, restic backup or borgbackup, zfs snapshot and zfssend).
If you use filesystem snapshots with delta sending you get performance and stability for free because it is in kernel space implemented. Userspace backup software has also advantages because you are less bound to specific kernels and filesystems.
Insofar as Syncthing can transport files from A to B it can be used as part of a backup solution. But a backup solution as a whole requires lots of functionality Syncthing lacks - point in time snapshots and the ability to restore from them, for one.
Exactly, I use Syncthing to sync or push files to central places and backup with periodic cron jobs from there. Which IMHO is a robust and reproducable solution.
To call Syncthing backup software is missleading and incorrect⌠I removed it from the list.
Notice Rsync wasnât on the list either⌠My backup solution is based on Rsync but it isnât backup software.
Any idea why my desktop displays a white window after multiple FULL reinstalls?
Canât get it to work my home isp requiers their router and you canât foward, open or lease anything, i canât foward any portsâŚ
You guys might want to take a look at Veeam, just for the sake of comparison before going and re-inventing the wheel yet again.
It is kind of hard to justify putting all of the time and effort into an open source project when such well matured free alternatives exist, albeit closed-sourced, but nonetheless still excellent software.
Edited by calmh to remove links that look like spam, while retaining the messaging.
Dude, seriously? Iâm not a spammer. Are you seriously censoring me from mentioning Veeam Free Backup?
No, Iâm just removing multiple links from the first post of a user who joined to read just one topic and within minutes post a reply full of links. Welcome to the forum.
I disagree - backup is one point where open source is not only nice to have, but very important to me (mostly for being future-proof). I do agree that there are already great backup solutions (open source) out there and donât really understand the point of making Syncthing another one (obviously I see the point why it would be awesome if the same application could do both synchronization and backups, but thatâs true for many things ).
Well, based on experience with some the softwares that call themselves backupâŚsyncthing is a rocking backup solution. Windows internal backup has its issues, even huge paid backup systems have their.
So most of this thread is just a wordplay. Syncthing as it is with properly set versioning gives a cool intime backup option having its own drawbacks - easy acces to older versions being the biggest pain. While some of the drawbacks are very opinion based - should really the amount of used space be primary thing for backup? I preffer easy acces to the backed files just as they are in the filesystem - no need to run an app, navigate thru it and hope it can pull the required file from its superextracomplicated megafile.
I understand that developers dont want it to be called backup - every single glitch in stable would be a big problem, even a showstopper. Their target is different and possibility to use as a backup is resultfor the rest of us
There is a shitty ui for restore, which was proposed in the request and it made sense. If you have a better idea how to improve the UX, it would be interesting to hear.
When at least I say ârestoreâ in a backup context I mean from a remote computer, after Iâve fried my local files in some way. No disrespect to the versioning restore UI, itâs just something orthogonal.
Well, not 100%! In above diagram the error is the two way arrow between âSyncthing networkâ and âLocal Serverâ. It should be a one way arrow, from the network to the local server, this is about making backups. Besides that, yes, thatâs what I implemented as well. I have a couple of clients that syncthing onto one machine. The synced folders on this machine are then hardlink backed up every night via dirvish (rsync based). That works fantastically.
And yes, syncthing is no backup software, it need not be. But I do think it can well be a solid part of a backup strategy. And here IMHO what Rasmus is asking is indeed not going in the right direction. Unix always had a tradition of:
Creating small tools that serve precisely one job and do it well.
Make those tools so that they can easily be plugged and piped - building blocks.
So using syncthing to mirror files onto another machine and then having dirvish backing them up is no different from piping dmsg into grep on the command line. All those tool do one great job - precisely one job. Combining many jobs gives great power and flexibility. Leave it that way.
Those here that do prgramming know what âencapsulationâ means in the OO context and they know the âsingle responsibilityâ paradigm. These are integral parts of building reliable software. Itâs the same here, dmesg, grep, syncthing, dirvish, etc. - they all have a single responsibility and they do kind of encapsulating the task they are doing.
So, yes, you may add encryption to the folder where synthing is offloading files - but even that is not really its job. Why you want encryption here is for a different reason, itâs about storing sensitive data on untrusted servers and providers on the internet. This has nothing at all to do with backups and only very little with syncing files. So my idea would be to keep these things - syncing, backing up and untrusted storage - separate. Synthing should definitely not get any backup functionality, there are plenty of open source backup solutions out there that can be used with syncthing.
I already got it that syncing to one machine and backing it up is a good idea, just syncthing for some reason doesnât like Inteno & Thompson(or thomson I donât remember) (default modem/router what basically everyone in Estonia has) paired with Teliaâs service (there are other isps, but noone really uses them)
The âbackâ part of the arrow is just there, so you are able to bring back your backup to the Syncthing network if necessary.
So if you restore from your backup, you can just put it in the correct folder in the local server and everybody gets the restored files⌠otherwise it might be a pain to get the files back into the network.
The âbackâ part of the arrow is just there, so you are able to bring back your backup to the Syncthing network if necessary.
Yep, we may argue about the way how to restore backups and everybody might prefer a different strategy here and it also depends on where you act (company or private) and what is being backed up (personal or shared data).
For me having to restore something is an exceptional occurence and happens rarely. My machine is setup so that the dirvish folders are RO-visible via a Samba share. That way users (AKA my family) can peek into their history and restore files themselves, I have no hassle with that. They copy files from a backup folder onto their machine and thatâs it. But thatâs mostly non-shared data, so that is fine. If in your case you have shared data then your approach is better, restore in the syncthing folder and have synthing role it out to the clients.
But this is also another indicator for not messing up syncing and backup. Everybody has different needs and restrictions and the beauty of *nix tools is that you can plug them according to those, getting precisely what you want.