3 ms·

If you were to start a web application from scratch, how would you deal with important database backups?

by markup 18y ago

hachiya 18y ago
http://forums.theplanet.com/index.php?showtopic=91115&view=findpost&p=599193 http://forums.theplanet.com/index.php?showtopic=91115&vi... This looks like a simple and safe way of handling repeated MySQL backups.
- markup 18y ago
  Yeah, I use a similar approach. However, for ma.gnolia we are talking about a database reaching half a terabyte (unless I misunderstood), so my question was more like: what do you people consider the best way to approach database backup so that it's sustainable, scalable and the most disaster proof? Got any testimoniance (whether personal or of public companies), or case study?
  - joshu 18y ago
    I wonder how they managed to get to half a terabyte. Delicious's was smaller even for millions of users.
    - markup 18y ago
      Yeah indeed... .5TB is huge for bookmarks (title, url, tags, description). I have never had the chance to build anything this big but if you imagine the amount of text you could fit in 500GB, it makes you wonder. I gave a look at your comments and found this one which replies to my question perfectly (I didn't follow that thread, discovered it right now): http://news.ycombinator.com/item?id=459000 http://news.ycombinator.com/item?id=459000 -- thank you for sharing your experience!
    - sjh 18y ago
      According to the write-up on Wired (http://blog.wired.com/business/2009/01/magnolia-suffer.html http://blog.wired.com/business/2009/01/magnolia-suffer.html), Ma.gnolia also took a snapshot of the page being bookmarked. This may account for the size of the database.
aristus 18y ago
Assuming your dataset or shards are reasonably small (<100GB): 1. Set up a replication slave on another server. 2. Periodically lock the slave while you back it up. 3. Copy files to 2 different secure locations. This gives you consistent backups that do not interrupt production, as well as a hot copy in case of some catastrophe.

If you were to start a web application from scratch, how would you deal with important database backups?

by markup 18y ago

If you were to start a web application from scratch, how would you deal with important database backups?

http://forums.theplanet.com/index.php?showtopic=91115&view=findpost&p=599193 http://forums.theplanet.com/index.php?showtopic=91115&vi... This looks like a simple and safe way of handling repeated MySQL backups.

markup 18y ago
Yeah, I use a similar approach. However, for ma.gnolia we are talking about a database reaching half a terabyte (unless I misunderstood), so my question was more like: what do you people consider the best way to approach database backup so that it's sustainable, scalable and the most disaster proof? Got any testimoniance (whether personal or of public companies), or case study?
- joshu 18y ago
  I wonder how they managed to get to half a terabyte. Delicious's was smaller even for millions of users.
  - markup 18y ago
    Yeah indeed... .5TB is huge for bookmarks (title, url, tags, description). I have never had the chance to build anything this big but if you imagine the amount of text you could fit in 500GB, it makes you wonder. I gave a look at your comments and found this one which replies to my question perfectly (I didn't follow that thread, discovered it right now): http://news.ycombinator.com/item?id=459000 http://news.ycombinator.com/item?id=459000 -- thank you for sharing your experience!
  - sjh 18y ago
    According to the write-up on Wired (http://blog.wired.com/business/2009/01/magnolia-suffer.html http://blog.wired.com/business/2009/01/magnolia-suffer.html), Ma.gnolia also took a snapshot of the page being bookmarked. This may account for the size of the database.

aristus 18y ago

Assuming your dataset or shards are reasonably small (<100GB): 1. Set up a replication slave on another server. 2. Periodically lock the slave while you back it up. 3. Copy files to 2 different secure locations. This gives you consistent backups that do not interrupt production, as well as a hot copy in case of some catastrophe.