I came across your software and it looks great. However, I am missing one feature. That is, that client encrypts user data with user’s password or key. This is a feature DejaDup does have (DejaDup is default backup software in Ubuntu Linux, however, it has several problems with stability and reliability).
Anyway, this feature would be great, because sometimes user wants to have his own data to be private and protected even from administrator. Sometimes administrator is not allowed to see that data (for. instance medical records, etc.). If user would be able to encrypt his own backup data and send that to backup server, administrator of a backup server will not have the option to see the data. In that case you eliminate the problem of trust in administrator. There is at least one person less, which would need a clearance, for example.
BTW: I have set up a VPN network. Machines in VPN network have IP addresses in range 10.10.7.0/24. One of the machine is a backup server. Users do not know it’s real IP address and it’s real location. Their backups are done on an encrypted disk. But additionally to that, users encrypt their data with their own (“local”) key/passphrase, so I (as administrator) cannot see the contents of their backups. Backups are also incremental.
This means, users have a secure off-site backup, which cannot be destroyed in case of a disaster on user’s location. Backups are stored on encrypted disk (so at server’s location) no one can see anything about user’s or their backups), and me as administrator cannot access their data.
It would be great if something similar would be possible with urBackup.
I would really like to see this feature added as well though I am exploring using ZFS filesystem encryption. I only perform image backups and I would not need the metadata encrypted but would need to have a key presented in order to mount any image backups.
Well, the idea is simple. User must retain control over his/her data and administrator should not have the technical capability to see user’s data.
DejaDup, which is just GUI for Duplicity, creates a series of around 15 MB files with names like: duplicity-full.20161009T165325Z.vol18.difftar.gz.
In that case I have no idea what are the files, directory structure or timestamps. I can only see the amount of someone’s data, and even that is uncertain, because these are incremental backups.
Are there any workaround alternatives that anyone is using to achieve the same right now? For example maybe for Windows image backups, bitlocker could be enabled on the guest OS so that the resulting vhd file will be encrypted?
Bitlocker would encrypt the disk but it doesn’t prevent the system operator from accessing the data in the backups.
I think that is the request.
To split the backups into encrypted chunks on the client side and transfer the encrypted chunks to the server. Where in the password exists on the client side agent and not within the server architecture.
Preventing the server operator from accessing the data on the back end.
This will require some serious delta magic that is beyond me personally but I would support the cause to see it happen.
Hi, I am currently switching from CrashPlan and I found UrBackup a perfect replacement but this feature is really missing. My server is accessible from the internet and I like to know that my personal backups from all my families PC’s are secure even if someone hacks my server.
I’m likewise in a forced migration from CrashPlan, since thety elected to dump thwe entire CP-Home userbase… and I was using the free P2P backup tier for catching backups from family and this feature would be “nice” to have
Could you please elaborate wrt. to those questions? Also what kind of threads you are expecting the encryption to thwart.
Problem is, to do it properly it would have to be done like borg or restic are doing it and then the server is more or less a relatively dump object/blob storage which is kind of opposite from what it is doing currently.
Another vote for some sort of encryption at the server. I’ll try to MacGuyver something on mine but it’s a serious requirement for anybody storing financial or medical data (businesses anyway).
I would also like to see an encryption possibility. For me it would be nice to let my clients know that administrators aren’t able to view file contents. But also, that the data is not retrievable from the hard disks in case they are removed.
Most software encrypts the data on the client, then stores that on the server. But this would break deduplication afaik.
Would it be possible to create containers per user. Those containers are encrypted. So deduplication per client is still possible, only not between clients.
This container could then be mounted while the back-up is running. And unmounted afterwards.
The issue here is the storage of the encryption key. You could let the client software send the encryption key (or has) together with the start back-up command. The server mounts the container, back-up is done, unmount, everything is safe again.
If a client wants to restore a file from the web interface, metadata will be able to show all files and dates. But the key would be requested on the interface when the restore has to be performed.
Only problem to me seems to be the cleanup jobs on the server. But since deduplication would be per client in this case, the cleanup could maybe run as part of the back-up on the client.
These are some thoughts that passed my mind while thinking about encryption in urbackup, maybe there are some ideas you can use
If I may Jump on this topic it is both very interesting and fairly complex because you have to consider several different use cases and most people miss the fact that one of urbackup most interesting feature is that if the same file is present on multiple clients, urbackup will only save it once…
in terms of use cases, would it be fair to summarize the following ones:
I am ok keeping my backup files un-encrypted on my server and across my LAN but I want to encrypt it during transfer over the internet -> case already covered with internet server transfer.
I am ok keeping my backup files un-encrypted on my server and across my LAN but I want to encrypt it when sending a copy over a cloud storage -> (you can do that by using a third party tool copying the urbackup db to the cloud (arq/allwaysync/goodsync))
I want my backup files encrypted on my server -> can be achieved by using a bitlocker disk-wide encryption solution.
I want my backup files encrypted on the client side with a key unavailable to the urbackup server administrator -> would require some coding and break the option of not duplicating files on the urbackup server.
I want my backup files encrypted on each client sides seprately but I am ok if the urbackup server administrator can decipher any of them… -> would require coding but shouldn’t be a major challenge, one trick to deal with filenames, attributes, timestamps would be to replace them with a fingerprint (hash based) on the server side. This would allow to track duplicates without expliciting mapping it to a filename… just a pointer to the db of each client.
please feel free to comment if I missed something.
I’m fine with paying the space penalty for dedup only working per defined user (user gets one encryption key) Identical blocks/files/filenames would produce the same cypher text and could still be linked, but their privacy would be protected.
I’m providing backup space for family members, but I’m uncomfortable with having full access to their possibly private files myself, never mind if someone else gained access somehow.
On point 3 made by @ffsb “not if your backup storage is a Drobo” you can’t bitlocker/truecrypt/veracrypt a thin provisioned space.
I don’t insist encryption becomes mandatory, however, I would like to see it supported as a configurable option.
I’m also moving (forced) from CrashPlan and really need encrypted backups on server end, even at expense of losing deduplication. Basically scenario 4 in ffsb’s post. Without that I run into compliance problems.
I would like encryption for home because the backups are stored externally.
Because i am my own admins and the computers are backup belongs to me,
i wouldn’t mind to have either a single pass for all the clients or one per client or user.
Personally i wouldn’t mind a “rough” storage encryption that wouldn’t cover for example metadata and folder tree, as long as file names are encrypted.
My understanding is that it s not much more difficult to encrypt file names than file content, interesting data can still be extracted from the file names, for example try to attack a special file, whereas knowing that one folder contazins alot of files and another one very few wouldn’t help too much for an attacker.
Actually even rot13 for filesname and filecontent would protect against a brut scan of the file from a bot/worm.
Thinking about it, where to place the decryption key is slightly annoying.
To be done well, it would need to reside on client and not on server.
Then this cause a ton of complexity, however the main issue is basically bot or script kiddies that even given access to the server wouldn’t be able to du much if their tools doesn’t support urbackup decryption.
Another issue is that the storage is remotly hosted and can be looked at the the host , but again i think simple encryption is enough
Another issue is that the admin can read the user’s files, but solving this creates it s own pitfalls.
In case the key is per user or client
Maybe the key needs to be sent to the user by email in case the server has to be restore from scratch, as to make sure he received it at least once.
Eventually add an option to allow the admin to restore in case the user lost its key.
Because users wouldn’t care about not losing their key until they realise that they need it for restore.
For inter client dedup and different users having access to different clients, i wonder how that could work. Like gpg can encrypt for multiple recipient, but if you give access to a user after a backup, he wouldn’t be able to decrypt previous ones. Or maybe make a group key that can decrypt the backups and allow many users to decrypt that group key.
And if that’s possible to encrypt for different users, maybe that’s also possible to dedup between clients.
I wonder how much additional dedup occures between clients (30% ?). So i am not sure if the tradoff for supporting it would be that bad.
If encryption is implemented, if possible please add an encryption type as metadata for each backup.
So that it becomes possible to switch from from a some heavy pgp thing to a fast rot13 one in case i realise that there a cpu issue, without having to scratch all the backups for that client.
I looked at it before I went for this, I liked the look of it, however for me This: is a deal breaker for anyone backing up Windows clients. The issue (at the time of writing) is still open.
For a backup program the absolute requirement above ALL others is that restoring works properly, hence settling here rather than there.
[I am also a struggling crashplan refugee]
quick question about using duplicati in conjunction with urbackup:
urbackup does restore junction points properly AFAIK and store them in their own backup format…
so…
if you setup your urbackup server on your LAN for your everyday backup… then replicate the urbackup db and backups folders with duplicati (encrypted/compressed) to the cloud… is it fair to assume that the junction points of your clients are anyway hidden from duplicati embedded inside the urbackup images?
note: I haven’t tested restoring junction points yet… (only a very basic file restore so far…)
As noted by others, the encryption of user data when at rest on the server is critical. This server becomes the central location that stores all data from all clients (sensitive data or not). This of course makes the backup server a huge liability for data breach.
Especially in the case of people who were using the free P2P backup options of CrashPlan, the data is likely on servers that are not under full control (physical and logical security). This could be a friends computer or a VPS somewhere.
Having application specific encryption with its own passphrase, encrypted at the client would solve this.
I think, as also mentioned, many people are OK with losing some space savings of dedup when this feature is enabled.
As for the encryption key, I think one that is generated from a passphrase might be useful and easier to keep track of than a key file on the client.
