Due to the recent adaption of GDPR -General Data Protection Regulation in all EU countries and systems that server eu citizens, all personal data stored must be transferred and stored encrypted.
Is urbackup compliant with this? Is there a way to achieve this?
We back up user files to a urbackup server, and all the backups are stored unencrypted. This means that the admin can have full access to the files, not to say about a hacker.
According to the regulation, each users backup must be stored encrypted with a separate encryption key and only the user with the key must be able to restore the file.
Storing unencrypted backups is not an option in Europe countries any more, we have to encrypt in client side and store encrypted. Is there an option for this? Will this be implemented somehow?
At this time there is no way to store encrypted and the only feedback Iāve seen is that thereās no plans to add this.
An alternative that Iām using for one client is Syncrify backup client pushing the backups to an S3 compatible storage server. Client encrypts the data and it stays that way on the storage server. Client is only $50 for a one-time purchase. Duplicati 2.0 could do the same for free, but itās been ābetaā for over 4 years now so I couldnāt trust it, but many other people like it.
I 've seen these solutions and they are pretty good. I was wondering if I could do this with urbackup.
Itās not about the money, we use urbackup almost 2 years and we find it quite useful because it can backup over the LAN when a laptop is in the company and over internet when it leaves. Itās quite fast and the way it manages its files is space saving. I would prefer in house storage that cloud.
The only solution Iāve come up with is to use a temp folder to store an encrypted copy of the file and then backup this folder, but I need twice the storage space.
I believe that this should be in the roadmap of urbackup because nowadays client-side encryption is a must.
I hope one day urbackup can encrypt the backupā¦ seafile do it natively so why not?
Due to some trouble about personal data lot of users ask us about data access, it appears itās become a base now. Perhaps in a future roadmap?
What if you run truecrypt and have the urbackup server store all your data within an encrypted container fileā¦
This way the urbackup server will just see a regular file system and be able to continue using hashing etc for dedup.
Although Iām not sure that truecrypt supports expanding containers. That would be a major issue.
Maybe an encrypted virtual drive would be betterā¦
Just thinking out loudā¦
the backup has to be client side encrypted, encryption on the server is almost useless us anyone that has access to the server can read the files.
The GDPR deadline is fast approaching. I may have to abandon backup altogether if there is no client encryption. 
I really do not want to give up as urbackup ticks every other box and has served me well.
Soā¦ what if the server generated a random password for each client and then added the password to the client settings (along with a countdown and daily message insisting it is changed or backup will cease). This would be much less work than having to remotely change each client.
So the client encrypts the data using the password and leaves the files encrypted when stored on the server. The file hashes could presumably be left in a raw format.
I understand this will cause the urbackup deduplication from working and result in larger storage requirements but this is a better option than scrapping the entire backup service. The dedup could possibly be reintroduced at a later date using the raw file hashesā¦
If I had the time and skills to do this myself I would but as I donāt I am happy to pay for this feature as I am sure other European users would.
I would also be happy to pay for this feature.
But please. GDPR does NOT require you to encrypt all backups. GDPR requires you to make sure you do everything in your power to secure data. Which might just as well be a server no-one can reach.
This is actually the relevant article:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
1) the pseudonymisation and encryption of personal data; 2) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; 3) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; 4) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
Now in which case it is appropriate to encrypt backups (and at what cost) is a matter for the courts to decide. It also conflicts a bit with the āabilityā in the same article.
Another one relevant to backups is the āright to be forgottenā Art. 17 GDPR ā Right to erasure (āright to be forgottenā) - General Data Protection Regulation (GDPR) .
If a user wants to be forgotten, youād also have to delete the data from backups (or donāt keep backups too long). But on the other hand you have to keep around data for tax purposes (for up to 10 years) including personal data (for VATMOSS).
The best way to implement both is to encrypt personal data with a per-user encryption key. But the key management is of course a lot of work (especially if the used applications arenāt integrated with a key management solution).
And with per-user encryption key I mean the e.g. the doctor taking notes on a patient saves the notes with an per patient encryption key.
I hear what youāre sayingā¦ but I still think it needs encrypting and Iād be more than happy to pay for the work involved.
Some of the backed up data is financial and legal documents. The owners of the data have specifically asked me if the backup is encrypted. I told them Iām working on itā¦ I donāt have the funds to go to court for months because some EU busybody realised itās not encrypted. I could just close the backup system but Iāve invested a lot of time and effort into getting it working so well.
UPDATE: AN EMAIL FROM ONE OF MY CLIENTS.
āHave you been able to sort out the General Data Protection Regulation rules with your man?
My problem is that from May Iād be in breach of FCA regulations if he isnāt compliant.
Iām happy to stay with you if you can confirm the cloud backup system is GDPR ready, or if itās not have you arranged any alternatives.
Please let me know were we stand going forward?ā
Any suggestions or will I should I just send the guy to another service provider?
Encryption is nice to have. But NOT a requirement. Donāt be so afraid of GDPR. Think about what you do, what the risks are, and keep stuff up to date.
You (and every other company on the world) are unable to be GDPR Compliant. There is no such thing.
Hello,
Iām just currious, what the option do you have for encryption with a urbackup server finally?
None. Unless I encrypt and resilver all 20 drives. Which would take months.
I am not sure how this would with GDPR because I am not 100% up on that, but my urBackup server is a Windows 2012 server and if needed I could just use bitLocker on the storage drive where the backups are. So my backups would be be encrypted at rest.
Bitlocker seams to be the good response 
7z is an excellent archiving software offering high compression ratio and strong AES-256 encryption.
If there is any way to implement that for urbackup then we are good to go with encrypted backups.
I did not try it yet cuz where I put urbackup they dont give a fuck about GDPR
but my plan if they change mind is to put backups on ZFS pools with native encryption.
Kinda issue when I was reading on it was that old xeon server does not have AES instruction set, so not even sure if it would work or if it would be just slower and more cpu demanding during i/o
anyway, ZFS encryption is still only in development build, but I would expect it to be fine and on its marry way to build 8.0
Also not really sure whats the issue for people
- for windows enable bitlocker for the storage
- for linux use dmcrypt to encrypt storage drive
- or play with ecryptfs which encrypts on file level
Shouldnt those work just fine to get at rest encryption?
Theory :
Yes, but ideally peoples do not want only at rest encryption.
Peoples wants per client encryption that the server canāt even read.
But then if you need to restore the client; you need to gets the key/pass from a likely centralized location.
If a server get hacked, it most probably get hacked āliveā and allow access to the partition.
Hence why there s also this discussion about how to read the gdpr. That it s basically a best effort policy, which allows you to not follow it if for example it s prohibitively expensive to follow.
In that case the centralized location could also be the backup server.
Somehow this would not be much different from not encrypting the backups.
At that point i am assuming that a client canāt restore data to itself that itās not supposed to be able to. Restoring data from a different client be a very reasonable use case.
Usage:
Hence my suggestion to allow something like only rot13 encrytion (ok, any better password based encryption would do). This would at least avoid a hacker to simply search for file content like an easy to parse mail address and whatnot, he would need to know the app and how it works.