Our advice is to not directly back up software development files, or development environments such as Git or Eclipse. Instead, have a script periodically create an archive of the development files in a location that SpiderOak One or Groups is monitoring. There are several benefits of this. First, what the backup application has to watch is a single file that is updated infrequently rather than thousands of files and subdirectories, so system load is kept to a minimum. Second, what gets backed up is data at rest, so the possibility of file corruption and difficulties during recovery are minimized.
Apropos the second point, you should schedule the script to run during times that the files will not be in the middle of active change. You will also want the archive to be no larger than 1 GB or so. SpiderOak can handle larger files than that, but for performance reasons, the smaller the better. You can leave the archive uncompressed, because SpiderOak compresses everything it backs up in any case. If you must compress the archive before SpiderOak gets to it, gzip with the --rsyncable option is a good choice to not lose the advantage of SpiderOak's deduplication.
Software development files and development environments can be backed up as described above. They should not however be synced. There are ways to synchronize development files (e.g.
git pull) and we are not trying to duplicate such tools.
For more information on what to back up, see What Data to Select for Backup.