5 ms·

Show HN: I made tarbackup.com for you, what do you think?

18 points by nanch 14y ago

tisme 14y ago
See: tarsnap.com
- nanch 14y ago
  tarsnap looks nice. somebody else had mentioned that service too, I figured I'd go over some of the differences. tarbackup is free, tarsnap is $0.30/GB/mo; tarbackup doesn't require a separate client download; tarbackup was made just for fun, tarsnap is commercial; tarbackup uses a private server, tarsnap uses S3
  - micheljansen 14y ago
    How are you going to keep it free? What guarantee do you give that after trusting my data to you, you won't decide that your bandwidth and storage costs are getting out of hand and discontinue the service? Not trying to be a sour grape here and talk you down, but these questions matter if you see this as more than a hobby thing and are serious about it. If you plan to take this further: find a way to make it sustainable. If not: why not release the code?
    - nanch 14y ago
      I'll keep it free by not requiring payment! :) I've already put $2.5K+ into the box just for fun. I don't expect to recover any costs; I'm just providing a service for people. Even if nobody actually needs to restore their data, at least they could if they wanted to. There are no guarantees, but I have a 20Mb/5Mb internet connection that's just waiting to get some more use. The system is set up with 7+ TB of storage that'd I'd love for you to fill up, and I can afford putting more hard drives in when it gets to that point. http://www.piqd.com/tarbackup_server.png http://www.piqd.com/tarbackup_server.png This really is just a hobby thing for now. :) The code is already posted. https://github.com/nanch/tarbackup https://github.com/nanch/tarbackup
      - tisme 14y ago
        I think you must be quite surprised at the responses you're getting to your offer of a free gift. But some things are serious enough that them being free is a serious red flag. In other words, I've you had presented this as a commercial offering in stead of as a hobby and just for fun you would have given a better first impression, one that proved that you had thought through the problem before embarking on solving it. HN has been a pretty strong critic of the way tarsnap is being run (specifically from a marketing point of view), the collective view is not that it is too expensive but rather that it is not yet expensive enough and that it needs to appeal more to non-techies. You've solved none of the problems that tarsnap already solved and then on top of that you have added a whole pile of new ones. So I think that even though I applaud your generosity and your general approach that this is not going to go very far. Using 'tar' means you're targeting developers, most other people will have never even heard of tar other than that black sticky stuff. Developers know the value of their data better than anybody else does (or at least, they should) and they will evaluate a backup service based on that value.
        flatline3 14y ago
        > HN has been a pretty strong critic of the way tarsnap is being run (specifically from a marketing point of view), the collective view is not that it is too expensive but rather that it is not yet expensive enough and that it needs to appeal more to non-techies. If that's the collective view, then I strongly disagree with the first half. Tarsnap isn't cheap for an organization with data of any appreciable size.
        tisme 14y ago
        Most 'X' as a service concepts have a point where doing it yourself is the more cost efficient option. Backup is no exception to that rule. A service like this works best when you have a manageable amount of very precious data. If you have mountains of low grade data then likely you're better off rolling your own. After all, since tarsnap is a very nice layer on top of S3 there is always at least one competitor cheaper for bulk back-up (amazon) and even they charge a substantial amount of money for storage and bandwidth. Costs vs benefits. It's never been different and it never will be.
  - tisme 14y ago
    Tarsnap is secure, made by someone who understands security. Backups are synonymous with reliability and security. Trusting an unknown entity with free backups on a service made 'for fun' makes me wonder: - how long it will be around - how you plan to stay alive in the long run I really wonder if you've thought this one through. Backups are rarely if ever for fun, when you need them you need them badly.
    - nickwoodhams 14y ago
      Agreed, I am more confident with Amazon S3 as opposed to an undisclosed private server. I like that the instructions guided you through creating a secured tar file. I like the idea of Tar backups, but no offense to you, I just don't trust the reliability. You can't offer a resilient backup service entirely free, it just doesn't work. Storage costs money, and developers know that better than anyone else. That being said, the actual code looks pretty simple. Think you're on the right track here. Don't think I would pay for the service though.
    - nanch 14y ago
      You make some great points here, thanks for the feedback. The code for the server scripts is posted on git if you have any suggestions on the security end. http://www.github.com/nanch/tarbackup/ http://www.github.com/nanch/tarbackup/ - how long will it be around: for the foreseeable future - how I plan to stay alive in the long run: I don't see why the service would need to be shut down.
  - zalew 14y ago
    "tarbackup was made just for fun, tarbackup uses a private server" excelent selling points for a backup service.
ysleepy 14y ago
I see that you are passionate about this. After I wrote a paragraph about how you could use the hardware for a shell server, static (octopress/jekyll) website hoster etc. I realised, that free backups are actually really awesome. For people who cannot afford another service or dont have access to a credit card or else. Also fpr my most important data like code as a second backup if all goes wrong. Thanks for the service, I will probably actually use it. But it being a fun project and only behind 5mbit upload, this is obviously not a professional solution or could be offered for money.
- nanch 14y ago
  "Free backups are really awesome." love that line :) My pleasure, I hope you do use it! We'll see how much use it gets. I could put the box on a 100mbps if people start using it.
Cyranix 14y ago
Your Git repo doesn't inspire confidence for usage by the public at large. If you want to continue using it, I would recommend that you change it over to friends-and-family access while you improve it. A few things that don't impress me right off the bat: * text file for queue of users to create * not accepting passwords with non-alphanumeric characters (and also not having the knowledge to recognize a use case for a regular expression) * using a static salt To be honest, I just stopped looking at this point. That's all without actually looking at the front-end of it (which has several typos, by the way -- when you're selling yourself to a very large audience, every detail counts).
- nanch 14y ago
  Thank you for looking over the code and providing your honest criticism. * the textfile doesn't seem like a problem to me, just another version of a DB, what would be better? * I updated the password to accept any password, not just alphanumerics * I updated submit.php to use a random 16-character salt rather than the static salt I'll look over the site to see if I can find those typos ;)
  - Cyranix 14y ago
    It doesn't seem to me that you're storing the per-user salt anywhere. I'm glad you're working on a project that is fun for you. It will be an opportunity for you to learn quite a lot, but I would urge you to question your design choices and keep asking "How could this be done better?". Read about how other people have approached similar problems. Get a small group of friends, family, and other technical acquaintances to pick this apart. I wouldn't endorse this for the general public.
    - nanch 14y ago
      The salt gets stored with the password hash in 'userstocreate.txt' so a line in userstocreate.txt looks something like: username:$6$salt$passwordhash$:email Then the password is sent to the /etc/passwd (/etc/shadow) file by /usr/sbin/useradd in createusers.pl.
genwin 14y ago
Thanks! I understand what this service is: free "cloud" backup, no guarantees. I have no problem with the latter part, given the former part. I'll use it accordingly and appreciate your gift.
- nanch 14y ago
  thank you! let me know if you have any problems or suggestions! my email is president@nanch.com
- jarek 14y ago
  > backup, no guarantees What's the use?
  - genwin 14y ago
    It's useful for a secondary or tertiary backup.
    - jarek 14y ago
      If your data is important enough that you want a secondary backup just in case both your main source and your backup are both taken out, you would presumably want it to be a reliable service, not a free hobby service on someone's home cable connection. If your data is not that important, why bother with secondary backup?
      - genwin 14y ago
        Good points. I already have three methods. This would be one more, in the extremely unlikely event that all the others fail. A fourth backup would be overkill if it wasn't free.
        jarek 14y ago
        I see the reasoning, but I can't help thinking that any event that would disable two or three well-planned backups is also rather likely to disable the fourth - especially if that one comes with no guarantees. I'm thinking that in the event of a major natural cataclysm, societal upheaval, etc, tarbackup.com is not going to be foremost on nanch's mind. I think this service could be most useful for spreading out the risk. For a user outside North America with a backup drive in their house and another backup somewhere else on their continent, adding an extra one in the U.S. might make sense. If your backups are already on S3 in Oregon it's probably realistically less useful.
JoachimSchipper 14y ago
From your "how to use" page: # echo mysupersecretkey > /backups/key # openssl enc -aes-256-cbc -salt -in fullbackup.tar.gz \ -out fullbackup.tar.gz.enc -pass file:/backups/key Please don't do this. openssl -aes-256-cbc is not a strong key derivation algorithm, so you need to use keys with much higher entropy (dd if=/dev/random of=/backups/key); an attacker can run through a dictionary of common passwords ridiculously quickly, thousands of times faster than when you're using a proper key derivation algorithm, e.g. bcrypt/scrypt/PBKDF2 to generate the key. If you do want to derive it from something akin to a password. More seriously, openssl -aes-256-cbc does not do any integrity protection; in fact, an attacker can more or less flip any bits of his choosing in the ciphertext to flip those same bits in the plaintext. (Yes, I'm aware it's a tiny bit more complicated than that.) It is possible to fix both of the above, but may I recommend gpg --symmetric as a simple and reasonably secure alternative?
- nanch 14y ago
  Great feedback, I'll change the "how to" ASAP after some reading on the subject. Is there a secure command option that I can use with openssl instead of -aes-256-cbc? I originally tried to provide an example for openssl and gpg, but the gpg example ended up with a dependency on X11 via a dependency on pinentry so I took it out for simplicity.
  - JoachimSchipper 14y ago
    OpenSSL sadly does not offer any authenticated encryption modes, so you cannot just replace -aes-256-cbc by something and be secure. There are basically two things that work: either authenticate the ciphertext [1] by having the user store a secure hash of each archive ("openssl sha512"), or switch to public-key crypto. Since the first is just inviting disaster - users aren't actually going to verify hashes - I recommend the second option. It's possible to build this on top of "openssl pkeyutl", but gpg is a lot nicer. If I were you, I'd just use gpg - some OSes/distros may pull in lots of stuff, but requiring a running (as opposed to installed) X server to run gpg is incredibly unlikely. [1] Always authenticate the ciphertext, never (just) the plaintext. See "padding oracle attack" for one practical reason why - getting a recognizable error when decrypting mangled ciphertext allows one to fully recover the plaintext. "Recognizable error" includes timing information. Just make sure you always authenticate the ciphertext.

18 points by nanch 14y ago

tisme 14y ago

See: tarsnap.com

nanch 14y ago
tarsnap looks nice. somebody else had mentioned that service too, I figured I'd go over some of the differences. tarbackup is free, tarsnap is $0.30/GB/mo; tarbackup doesn't require a separate client download; tarbackup was made just for fun, tarsnap is commercial; tarbackup uses a private server, tarsnap uses S3
- micheljansen 14y ago
  How are you going to keep it free? What guarantee do you give that after trusting my data to you, you won't decide that your bandwidth and storage costs are getting out of hand and discontinue the service? Not trying to be a sour grape here and talk you down, but these questions matter if you see this as more than a hobby thing and are serious about it. If you plan to take this further: find a way to make it sustainable. If not: why not release the code?
  - nanch 14y ago
    I'll keep it free by not requiring payment! :) I've already put $2.5K+ into the box just for fun. I don't expect to recover any costs; I'm just providing a service for people. Even if nobody actually needs to restore their data, at least they could if they wanted to. There are no guarantees, but I have a 20Mb/5Mb internet connection that's just waiting to get some more use. The system is set up with 7+ TB of storage that'd I'd love for you to fill up, and I can afford putting more hard drives in when it gets to that point. http://www.piqd.com/tarbackup_server.png http://www.piqd.com/tarbackup_server.png This really is just a hobby thing for now. :) The code is already posted. https://github.com/nanch/tarbackup https://github.com/nanch/tarbackup
    - tisme 14y ago
      I think you must be quite surprised at the responses you're getting to your offer of a free gift. But some things are serious enough that them being free is a serious red flag. In other words, I've you had presented this as a commercial offering in stead of as a hobby and just for fun you would have given a better first impression, one that proved that you had thought through the problem before embarking on solving it. HN has been a pretty strong critic of the way tarsnap is being run (specifically from a marketing point of view), the collective view is not that it is too expensive but rather that it is not yet expensive enough and that it needs to appeal more to non-techies. You've solved none of the problems that tarsnap already solved and then on top of that you have added a whole pile of new ones. So I think that even though I applaud your generosity and your general approach that this is not going to go very far. Using 'tar' means you're targeting developers, most other people will have never even heard of tar other than that black sticky stuff. Developers know the value of their data better than anybody else does (or at least, they should) and they will evaluate a backup service based on that value.
      - flatline3 14y ago
        > HN has been a pretty strong critic of the way tarsnap is being run (specifically from a marketing point of view), the collective view is not that it is too expensive but rather that it is not yet expensive enough and that it needs to appeal more to non-techies. If that's the collective view, then I strongly disagree with the first half. Tarsnap isn't cheap for an organization with data of any appreciable size.
        tisme 14y ago
        Most 'X' as a service concepts have a point where doing it yourself is the more cost efficient option. Backup is no exception to that rule. A service like this works best when you have a manageable amount of very precious data. If you have mountains of low grade data then likely you're better off rolling your own. After all, since tarsnap is a very nice layer on top of S3 there is always at least one competitor cheaper for bulk back-up (amazon) and even they charge a substantial amount of money for storage and bandwidth. Costs vs benefits. It's never been different and it never will be.
- tisme 14y ago
  Tarsnap is secure, made by someone who understands security. Backups are synonymous with reliability and security. Trusting an unknown entity with free backups on a service made 'for fun' makes me wonder: - how long it will be around - how you plan to stay alive in the long run I really wonder if you've thought this one through. Backups are rarely if ever for fun, when you need them you need them badly.
  - nickwoodhams 14y ago
    Agreed, I am more confident with Amazon S3 as opposed to an undisclosed private server. I like that the instructions guided you through creating a secured tar file. I like the idea of Tar backups, but no offense to you, I just don't trust the reliability. You can't offer a resilient backup service entirely free, it just doesn't work. Storage costs money, and developers know that better than anyone else. That being said, the actual code looks pretty simple. Think you're on the right track here. Don't think I would pay for the service though.
  - nanch 14y ago
    You make some great points here, thanks for the feedback. The code for the server scripts is posted on git if you have any suggestions on the security end. http://www.github.com/nanch/tarbackup/ http://www.github.com/nanch/tarbackup/ - how long will it be around: for the foreseeable future - how I plan to stay alive in the long run: I don't see why the service would need to be shut down.
- zalew 14y ago
  "tarbackup was made just for fun, tarbackup uses a private server" excelent selling points for a backup service.

ysleepy 14y ago

I see that you are passionate about this. After I wrote a paragraph about how you could use the hardware for a shell server, static (octopress/jekyll) website hoster etc. I realised, that free backups are actually really awesome. For people who cannot afford another service or dont have access to a credit card or else. Also fpr my most important data like code as a second backup if all goes wrong. Thanks for the service, I will probably actually use it. But it being a fun project and only behind 5mbit upload, this is obviously not a professional solution or could be offered for money.

nanch 14y ago
"Free backups are really awesome." love that line :) My pleasure, I hope you do use it! We'll see how much use it gets. I could put the box on a 100mbps if people start using it.

Cyranix 14y ago

Your Git repo doesn't inspire confidence for usage by the public at large. If you want to continue using it, I would recommend that you change it over to friends-and-family access while you improve it. A few things that don't impress me right off the bat: * text file for queue of users to create * not accepting passwords with non-alphanumeric characters (and also not having the knowledge to recognize a use case for a regular expression) * using a static salt To be honest, I just stopped looking at this point. That's all without actually looking at the front-end of it (which has several typos, by the way -- when you're selling yourself to a very large audience, every detail counts).

nanch 14y ago
Thank you for looking over the code and providing your honest criticism. * the textfile doesn't seem like a problem to me, just another version of a DB, what would be better? * I updated the password to accept any password, not just alphanumerics * I updated submit.php to use a random 16-character salt rather than the static salt I'll look over the site to see if I can find those typos ;)
- Cyranix 14y ago
  It doesn't seem to me that you're storing the per-user salt anywhere. I'm glad you're working on a project that is fun for you. It will be an opportunity for you to learn quite a lot, but I would urge you to question your design choices and keep asking "How could this be done better?". Read about how other people have approached similar problems. Get a small group of friends, family, and other technical acquaintances to pick this apart. I wouldn't endorse this for the general public.
  - nanch 14y ago
    The salt gets stored with the password hash in 'userstocreate.txt' so a line in userstocreate.txt looks something like: username:$6$salt$passwordhash$:email Then the password is sent to the /etc/passwd (/etc/shadow) file by /usr/sbin/useradd in createusers.pl.

genwin 14y ago

Thanks! I understand what this service is: free "cloud" backup, no guarantees. I have no problem with the latter part, given the former part. I'll use it accordingly and appreciate your gift.

nanch 14y ago
thank you! let me know if you have any problems or suggestions! my email is president@nanch.com
jarek 14y ago
> backup, no guarantees What's the use?
- genwin 14y ago
  It's useful for a secondary or tertiary backup.
  - jarek 14y ago
    If your data is important enough that you want a secondary backup just in case both your main source and your backup are both taken out, you would presumably want it to be a reliable service, not a free hobby service on someone's home cable connection. If your data is not that important, why bother with secondary backup?
    - genwin 14y ago
      Good points. I already have three methods. This would be one more, in the extremely unlikely event that all the others fail. A fourth backup would be overkill if it wasn't free.
      - jarek 14y ago
        I see the reasoning, but I can't help thinking that any event that would disable two or three well-planned backups is also rather likely to disable the fourth - especially if that one comes with no guarantees. I'm thinking that in the event of a major natural cataclysm, societal upheaval, etc, tarbackup.com is not going to be foremost on nanch's mind. I think this service could be most useful for spreading out the risk. For a user outside North America with a backup drive in their house and another backup somewhere else on their continent, adding an extra one in the U.S. might make sense. If your backups are already on S3 in Oregon it's probably realistically less useful.

JoachimSchipper 14y ago

From your "how to use" page: # echo mysupersecretkey > /backups/key # openssl enc -aes-256-cbc -salt -in fullbackup.tar.gz \ -out fullbackup.tar.gz.enc -pass file:/backups/key Please don't do this. openssl -aes-256-cbc is not a strong key derivation algorithm, so you need to use keys with much higher entropy (dd if=/dev/random of=/backups/key); an attacker can run through a dictionary of common passwords ridiculously quickly, thousands of times faster than when you're using a proper key derivation algorithm, e.g. bcrypt/scrypt/PBKDF2 to generate the key. If you do want to derive it from something akin to a password. More seriously, openssl -aes-256-cbc does not do any integrity protection; in fact, an attacker can more or less flip any bits of his choosing in the ciphertext to flip those same bits in the plaintext. (Yes, I'm aware it's a tiny bit more complicated than that.) It is possible to fix both of the above, but may I recommend gpg --symmetric as a simple and reasonably secure alternative?

nanch 14y ago
Great feedback, I'll change the "how to" ASAP after some reading on the subject. Is there a secure command option that I can use with openssl instead of -aes-256-cbc? I originally tried to provide an example for openssl and gpg, but the gpg example ended up with a dependency on X11 via a dependency on pinentry so I took it out for simplicity.
- JoachimSchipper 14y ago
  OpenSSL sadly does not offer any authenticated encryption modes, so you cannot just replace -aes-256-cbc by something and be secure. There are basically two things that work: either authenticate the ciphertext [1] by having the user store a secure hash of each archive ("openssl sha512"), or switch to public-key crypto. Since the first is just inviting disaster - users aren't actually going to verify hashes - I recommend the second option. It's possible to build this on top of "openssl pkeyutl", but gpg is a lot nicer. If I were you, I'd just use gpg - some OSes/distros may pull in lots of stuff, but requiring a running (as opposed to installed) X server to run gpg is incredibly unlikely. [1] Always authenticate the ciphertext, never (just) the plaintext. See "padding oracle attack" for one practical reason why - getting a recognizable error when decrypting mangled ciphertext allows one to fully recover the plaintext. "Recognizable error" includes timing information. Just make sure you always authenticate the ciphertext.