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

Instapaper's backup method

marco.org

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Instapaper's backup method

#31

Post by heyitsnick »

portman wrote: post #21
joshu wrote: post #19

Earlier quoted context omitted.

Indexes cab certainly update. Pretty sure innodb does not table lock for delete either. Also from a privacy perspective you can't keep people's data around forever.

Maybe this is overly pedantic, but you can do whatever you want with people's data, so long as you inform them of your policies and they agree to them.

I doubt that's true, at least in the UK. Terms and conditions cannot trump your personal rights. We have these terms laid out in the Data Protection Act and I doubt you can sign this away be agreeing to a website policy that contradicts them.

Re: Instapaper's backup method

#32

Post by jschuur »

mseebach wrote: post #3

It seems unnecessarily exposed to an event affecting Marco's home - fire, burglary, natural disaster etc. It would appear more prudent to back up to a cloud location. Either, as he mentions, S3, or a VPS somewhere.

One of his earlier tweets that led to this article suggests it's not just backed up at his home:

“I should blog about Instapaper's backup setup sometime. It's pretty extensive. A lot of places would need to burn down to lose your data.”

Maybe he just likes having a complete copy of the production data on his local development instance? Great for local data ming too.

Re: Instapaper's backup method

#33

Post by joshd »

tlack wrote: post #4
mseebach wrote: post #3

It seems unnecessarily exposed to an event affecting Marco's home - fire, burglary, natural disaster etc. It would appear more prudent to back up to a cloud location. Either, as he mentions, S3, or a VPS somewhere.

The problem with backing up with S3 is that if you ever stop paying for S3 you lose your backups. If you get sick for a month and your bank balance goes negative, or the IRS takes control over your account for something, there go your backups. I find that to be way more scary and likely than losing all of my DVD backups.

Another issue is that your S3 credentials are stored on your primary server. An attacker who gains access to that machine will also gain access to off site backups, and can completely destroy your business.

Re: Instapaper's backup method

#34

Post by ludwigvan »

[Disclaimer: Instapaper fan here, so my opinions might be biased. It is probably the application I love the most on my iPad and iPod Touch. Thanks Marco!]

Marco has recently left his position as the CEO of Tumblr; and I think concentrates on Instapaper much more than ever (I assume it was mostly a weekend project before, requiring simple fixes); therefore I have no doubt he will be making the service more reliable and better in the future (switch to S3 or similar).

Also, don't forget that Instapaper web service is currently free, although the iOS applications are not (There is a free lite version too.) There is a recently added subscription option (which AFAIK currently doesn't offer any additional thing); and I hope it will only make the service even better.

About security, I do not consider my Instapaper reading list as too confidential; so I don't have much trouble thinking the backup computer being stolen. Of course, your mileage might vary. As far as I know, even some accounts do not have passwords for Instapaper, you just login with your email address.

Re: Instapaper's backup method

#35

Post by albertzeyer »

heyitsnick wrote: post #31
portman wrote: post #21

Earlier quoted context omitted.

Maybe this is overly pedantic, but you can do whatever you want with people's data, so long as you inform them of your policies and they agree to them.

I doubt that's true, at least in the UK. Terms and conditions cannot trump your personal rights. We have these terms laid out in the Data Protection Act and I doubt you can sign this away be agreeing to a website policy that contradicts them.

Same Thing in Germany. The Law always has priority over whatever you write.

Re: Instapaper's backup method

#36

Post by petercooper »

bl4k wrote: post #26
larrywright wrote: post #15

Earlier quoted context omitted.

It's not explicitly stated in the article, but in the tweet that started it all[1], he mentioned it was a Mac Pro, rather than a laptop. So that's somewhat less likely to be stolen than a laptop that is taken out of the house regularly. That said, I agree with you, and I hope it's at least encrypted. [1] http://twitter.com/#!/marcoarment/status/6035374438621184

ye not much better there is a reason datacenters were built thinking about this after I left my comment, having all that data on your local machine is just crazy - you are one browser exploit or break-in away from having it fall into somebody elses hands. It isn't professional for a web service to be doing this - esp one that is now charging some customers.

In principle, this is true, but we're talking Instapaper here. The only sensitive data that could be in a list of URLs is if you were making a bunch of porn or subversive literature to "Read Later." It's not on a par with financial info or even personal notes.

Re: Instapaper's backup method

#37

Post by konad »

I just dump data into Venti and dump my 4gb Venti slices encrypted to DVD and keep an encrypted copy of my vac scores distributed around my systems.

If you're doing full dumps every few days, you're doing it wrong.

Re: Instapaper's backup method

#38

Post by zdw »

adambyrtek wrote: post #22
zdw wrote: post #17

Earlier quoted context omitted.

Regarding point #1 - Marco's "Home Computer" is a Mac Pro (per other posts he's made) - it has Xeon proceesors, ECC RAM, etc. Much closer to a server than what you can pick up at Best Buy for $399.

It's not about performance nor price, but conditions in which the machine operates. Many servers used nowadays are cheaper than high-end desktop machines.

Obviously most people misunderstood my GP post...

The point wasn't that his system was in some way adequate because he happened to be using one good piece of kit, but that that particular piece of kit was better than average.

Additionally, the GGP post makes some assumptions about acceptability of backup procedures that may not be correct - for example, that in Instapaper's case anything but the most current backup copy would be useful, and therefore long term storage of older copies isn't of primary concern.

Re: Instapaper's backup method

#39

Post by asb »

joshd wrote: post #33
tlack wrote: post #4

Earlier quoted context omitted.

The problem with backing up with S3 is that if you ever stop paying for S3 you lose your backups. If you get sick for a month and your bank balance goes negative, or the IRS takes control over your account for something, there go your backups. I find that to be way more scary and likely than losing all of my DVD backups.

Another issue is that your S3 credentials are stored on your primary server. An attacker who gains access to that machine will also gain access to off site backups, and can completely destroy your business.

I was under the impression that using S3's versioned object support, it's possible to set up an account that has the ability to write objects but not to delete previous versions.

Re: Instapaper's backup method

#40

Post by mwg66 »

petercooper wrote: post #36
bl4k wrote: post #26

Earlier quoted context omitted.

ye not much better there is a reason datacenters were built thinking about this after I left my comment, having all that data on your local machine is just crazy - you are one browser exploit or break-in away from having it fall into somebody elses hands. It isn't professional for a web service to be doing this - esp one that is now charging some customers.

In principle, this is true, but we're talking Instapaper here. The only sensitive data that could be in a list of URLs is if you were making a bunch of porn or subversive literature to "Read Later." It's not on a par with financial info or even personal notes.

Who are you to say what conclusions can or cannot be drawn between a persons name and a list of URLs they chose to read? I can think of many, undesirable and potentially erroneous conclusions that could be made.
Post reply on HN