4 ms·

This git backup approach is crap. Pure crap. Sorry to lower the tone on HN, and I'll get to the _reasons_ soon, but my brain overloaded at how over-engineered

by tezza 17y ago

This git backup approach is crap. Pure crap. Sorry to lower the tone on HN, and I'll get to the _reasons_ soon, but my brain overloaded at how over-engineered this problem is. ------------------ Deterministic SQL Output :: For the delta set in git not to jump around, the ordering of the statements MUST BE THE SAME every time. git is designed for source code Trivial Amounts of Space Saving :: just creating a well known bz2 of the file is going to give you excellent compression, and then you can save it to S3 / DropBox, your home computer ALTER TABLE :: ALTER TABLE or any UPDATE * is going to yield a line by line delta... checking in the whole DB/Table again. Given that this is app specific, WHY not just compress the whole dump. Backup Complexity :: You've written a cron script, validated that the whole db is being dumped, hdd space is cheap, so why involve another step that can go wrong? Duplicating a tar.bz2 file is a lot easier to validate than a git commit. Much much much faster too.

pilif 17y ago
MySQL usually does not reorder the data on disc, so in the OP's case, this might actually work for him. I do agree though that just moving around bz2 files is much easier. Andit scales better (as in: continues to work) once you begin accumulating REAL data. A common size for a complete dump of one of the plattforms I'm working with is 400 MB bzip2 compressed. You certainly would not want to have that amount of data uncompressed in a git repository. should you decide to compress pre giting, you of couse lose all advantages of using fit for this in the first place. This feels like a non-solution to me
maw 17y ago
All well and good, except that git doesn't explicitly store delta sets. Which doesn't mean storing SQL dumps in git is or isn't a good idea, but the git repository itself probably won't bloat up too much just from moving stuff around in a file, especially if the initial commits were small.

by tezza 17y ago

pilif 17y ago

MySQL usually does not reorder the data on disc, so in the OP's case, this might actually work for him. I do agree though that just moving around bz2 files is much easier. Andit scales better (as in: continues to work) once you begin accumulating REAL data. A common size for a complete dump of one of the plattforms I'm working with is 400 MB bzip2 compressed. You certainly would not want to have that amount of data uncompressed in a git repository. should you decide to compress pre giting, you of couse lose all advantages of using fit for this in the first place. This feels like a non-solution to me

maw 17y ago

All well and good, except that git doesn't explicitly store delta sets. Which doesn't mean storing SQL dumps in git is or isn't a good idea, but the git repository itself probably won't bloat up too much just from moving stuff around in a file, especially if the initial commits were small.