Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Baxx – Unix-friendly backup service

txt.black

Post reply on HN
Print view View original

151–160 of 203 posts

Re: Show HN: Baxx – Unix-friendly backup service

#151

Post by rakoo »

ekovarski wrote: post #143
spasche wrote: post #120

Earlier quoted context omitted.

One big disadvantage of restic at the moment is that it doesn't do compression ( https://github.com/restic/restic/issues/21 ). I was using restic and switched to borg because of that and could save hundreds of gigabytes.

You can always back up onto a compression enabled file system to further save space + dedupe with rustic. Borg is a fantastic tool but the time it takes to start and parse the files req on a large system negates the benefits of compression for me unfortunately.

Encryption totally defeats any raw compression. It would need to be inside the blobs themselves.

Re: Show HN: Baxx – Unix-friendly backup service

#152

Post by marci »

helper wrote: post #87

Registration over ssh is cute but not safe from MITM attacks. Even if the ssh key was published somewhere (which as far as I can tell it isn't) you would be dependent on people manually adding the key to their known_hosts file which you can't reasonably expect most people to bother with.

You can't reasonably expect most people who would register to a service over ssh and make backups with cUrl in a shell script to update their known_hosts file?

The instructions on the main page would change from:

  ssh register@ui.baxx.dev
to something like

  curl https://ui.baxx.dev/ssh_keys -o /tmp/baxx_ssh_keys
  cat /tmp/baxx_ssh_keys
  cat /tmp/baxx_ssh_keys >> ~/.ssh/known_hosts
  rm /tmp/baxx_ssh_keys
  ssh register@ui.baxx.dev
or in one line:

  curl https://ssh_key.baxx.dev >> ~/.ssh/known_hosts && ssh register@ui.baxx.dev

Re: Show HN: Baxx – Unix-friendly backup service

#153

Post by throwawaymath »

blattimwind wrote: post #138
throwawaymath wrote: post #136

Earlier quoted context omitted.

I'm not the person you responded to, but here are my observations: 1. Borg's authenticated encryption is a composition of AES-256 in CTR mode and HMAC-SHA256 (or alternatively, Blake2b256). This consists of two distinct constructions. Most cryptographic vulnerabilities are introduced in the combination of distinct primitives and constructions. While combining AES-CTR and HMAC is a way of doing authenticated encryptio…

The AES/MAC composition itself in Borg is done correctly, the problem is the way Borg uses the composition: with a single AES/MAC key for the entire repository which a) never changes b) cannot be changed and c) IVs/nonces used with those keys are primarily tracked by server-side, i.e. untrusted, state. This means that using multiple clients with one repository is never secure in Borg. > It would be much better to use…

Can you walk me through how AES-GCM or ChaPoly breaks authenticity and confidentiality, but AES-CTR doesn't? I'm not following you.

Moreover, I'm pretty sure Borg's developers are actively considering ChaPoly for the future.

Re: Show HN: Baxx – Unix-friendly backup service

#154

Post by zulgan »

arendtio wrote: post #109

Two reasons why I do not want to use the service in its current state (meant as constructive criticism): 1. If I would send my backups to some SASS there is no way I would do that without encryption. 2. I like to backup my filesystem and not just the files in it (to make sure I've got everything and make restoring easy). Currently, I just dd my block devices, but I am sure that could be optimized to not upload a comp…

tbh you I wouldnt trust anyone with my encryption, that is why in Baxx I advise people to simply upload encrypted

  cat file | encrypt -k .pass | curl --data-binary
  cat file | encrypt -k .pass > file.enc && curl -T file.enc https://baxx.dev/io/$BAXX_TOKEN/file
(encrypt: https://github.com/jackdoe/updown/blob/master/cmd/encrypt/ma...)

offtopic: it is a bit annoying that cat | curl makes curl buffed the whole standard input, so for big files you have to either you have to do -H "Transfer-Encoding: chunked" or use -T file

2) dd block devices is very fragile, its better if you just tar --exclude/dev ... (https://help.ubuntu.com/community/BackupYourSystem/TAR - Alternate backup)

Re: Show HN: Baxx – Unix-friendly backup service

#155

Post by zulgan »

gojomo wrote: post #54
kiallmacinnes wrote: post #20

Earlier quoted context omitted.

I think the intent is that, there is no web UI for the product itself. The UI for product itself is a terminal program, accessed via either SSH, or a web based terminal client. The product UI has zero HTML/CSS/etc.

The website https://ui.baxx.dev is, in fact, serving HTML, CSS, and JS. I get the point, but the "without a website" claim is kind of a cutesy attention-grabbing prevarication. I'm usually pretty tolerant of those, but personally find that here it mixes poorly with the idea of a backup service. From such a service, I'd prefer to see total honesty, and a sort of buttoned-down, almost military humorlessness/seriousness…

I setup shellinabox for https://ui.baxx.dev just because some of my friends dont have access to ssh from work and I wanted to show it to them

Re: Show HN: Baxx – Unix-friendly backup service

#156

Post by dchest »

throwawaymath wrote: post #153
blattimwind wrote: post #138

Earlier quoted context omitted.

The AES/MAC composition itself in Borg is done correctly, the problem is the way Borg uses the composition: with a single AES/MAC key for the entire repository which a) never changes b) cannot be changed and c) IVs/nonces used with those keys are primarily tracked by server-side, i.e. untrusted, state. This means that using multiple clients with one repository is never secure in Borg. > It would be much better to use…

Can you walk me through how AES-GCM or ChaPoly breaks authenticity and confidentiality, but AES-CTR doesn't? I'm not following you. Moreover, I'm pretty sure Borg's developers are actively considering ChaPoly for the future.

GCM/Poly1305 require unique nonces, so if they are repeated, the authenticity is broken. HMAC doesn't need nonces, so authenticity is preserved as long as the key is secret.

Re: Show HN: Baxx – Unix-friendly backup service

#157

Post by helper »

marci wrote: post #152
helper wrote: post #87

Registration over ssh is cute but not safe from MITM attacks. Even if the ssh key was published somewhere (which as far as I can tell it isn't) you would be dependent on people manually adding the key to their known_hosts file which you can't reasonably expect most people to bother with.

You can't reasonably expect most people who would register to a service over ssh and make backups with cUrl in a shell script to update their known_hosts file? The instructions on the main page would change from: ssh register@ui.baxx.dev to something like curl https://ui.baxx.dev/ssh_keys -o /tmp/baxx_ssh_keys cat /tmp/baxx_ssh_keys cat /tmp/baxx_ssh_keys >> ~/.ssh/known_hosts rm /tmp/baxx_ssh_keys ssh register@ui.ba…

The author of this service didn't think it important to provide the ssh key and based on the comments in this thread people have already signed up for this service without caring about the key. So yes, I think even people who would use this service mostly can't be bothered to manually update their known_hosts file.

Re: Show HN: Baxx – Unix-friendly backup service

#158

Post by zulgan »

helper wrote: post #87

Registration over ssh is cute but not safe from MITM attacks. Even if the ssh key was published somewhere (which as far as I can tell it isn't) you would be dependent on people manually adding the key to their known_hosts file which you can't reasonably expect most people to bother with.

You are right.

it is super cute though, I still get excited every time I try the registration flow.

the registration api is quite easy (https://baxx.dev/help/register)

  curl -d '{"email":"your.email@example.com", "password":"mickey mouse"}' \
 https://baxx.dev/register
I will probably do make register.sh endpoint that returns a bash script that runs local dialog like: curl https://baxx.dev/register.sh | sh (just idea, not implemented yet)

this will be fun, making portable tty dialogs :D

Re: Show HN: Baxx – Unix-friendly backup service

#159

Post by johntash »

linsomniac wrote: post #146
johntash wrote: post #107

Earlier quoted context omitted.

I've used both Borg and Restic pretty heavily. I settled on Restic because it was much lighter on resources. A few of the servers I manage have small amounts of ram, but large amounts of data. Borg would often get oom-killed, but Restic wouldn't. Restic also starts uploading changes as soon as it sees them, whereas borg has to scan the entire list of files before it starts uploading changes. Unfortunately for multi-t…

Interesting. I had deployed restic to my fleet of 100 servers around a year ago to backup to a common Backblaze B2 destination, and rolled it back after running into a production service getting OOM killed because of restic memory use.

That's interesting, did you have a lot of small files or large files?

I don't know if it's an option for you, but have you considered something like rsync from each server to a central backup server and then running restic/borg/whatever on that server? Sometimes that works out nicely too, and would be less impactful to other services on the machine.

What did you switch to instead of restic, if you don't mind me asking?

Re: Show HN: Baxx – Unix-friendly backup service

#160

Post by johntash »

mholt wrote: post #125
spasche wrote: post #120

Earlier quoted context omitted.

One big disadvantage of restic at the moment is that it doesn't do compression ( https://github.com/restic/restic/issues/21 ). I was using restic and switched to borg because of that and could save hundreds of gigabytes.

IMO compression in backups is overrated. (I run Relica, a backup service built atop restic: https://relicabackup.com ) Most large files are already in compressed formats: mp4, zip, tgz, jpg, etc. What you _really_ want is deduplication (which restic does), so that chunks are only stored once, even if multiple machines sharing some data back up to the same repo. Dedup saves me about 30% per backup repo in my own exper…

I agree that compression is overrated for most backups. It'd help with a lot of text-oriented data, but honestly that takes up so little space compared to a vm image or something like that.

If I was backing up a single computer, compression would matter more to me. But if I'm backing up 10s or 100s of servers, there's going to be a lot of duplicated data that would make a much bigger difference.

Post reply on HN