...only one is 28...
Backup is good, backup is nice, but you have to make it and test it. And you also need to hold onto it. Because if you make it and then throw it away, is useless.
When the world was jounger and backup was done using those magical things called TAPES, and when you mention them today everybody looks at you like you're a martian arrived from... well... Mars... Yoh! Have you ever saw Star Wars? Even the Death Star plan were on "tapes" eh! Yes, a technology that can manufacture faster-than-light-ship and lightsabers and they still uses tapes for storage. Well...
Anyhow, when we were using tapes for the backup, what we did was to use different tapes for different days. We had daily tapes, weekly tapes, monthly tapes and so on. This way we could go back in time until we could recover what we were looking for. That meant to have A LOT of tapes and ORGANIZED.
Stuffing in the library yesterday's tapes instead of last week's ones meant to live the whole week in the fear that somebody would show up and ask for a restore of just that date. Tha usually happened (Murphy).
Obiously, tapes were expensive and bulky, using money and space that could have been used for a lot of other things, but if you want to sleep at night...
Today... Today everything is "cloud". That basically means that the "backup" are in the cloud too. That can be good or bad, it depends.
On the 'good' side, backup means, mostly, to put a check in the box that says "take a snapshot every X hours".
On the other side, that would be the "bad" one, this also means that when you need to do a restore, first you have to figure out where the fuck is your snapshot and what's is name and how do you use it and then you'll have to figure out if you can just grab one file or you need to rebuild the whole fucking machine and then go pick up your file. And that normally this takes a lot of time, coffee and swearing.
Oh and you also need to check how much space all these "snapshot" are using, before you get a multi-billion invoice for "archive space".
And this bring us to today's argument: retention. No, ain't a swear word. Yet. It means that data that are "not very much useful", being it old backups or old logs, have to be stored for a while and then have to be destroyed because they are using space that could be used for something else.
Now, everybody has his own way to manage the data retention, somebody makes monster scripts/application that generates dozens upon dozens of 'reminder' and move stuff in or out 'warm-storage' or 'cold-storage' or 'wtf-storage' or wathever before throwing everything into the shredder, somebody does everything by hand (if the things are manageable)... and who, in many cases, doesn't do squat until something doesn't blow up in his face.
And speaking of "blowing up in your face", let's talk about $salesAndDeals, a company that managed 'vouchers' and 'discount tickets'.
These peoples had a system based on a web site that looked like it had been designed by somebody used to work in Fortran. First of all, every time a change had to be done on a table of the database, the table was copied into a new one with the date added to the name and the changes were done in the copy. The program was designed in such a way that always picked the last table available. This meant that in the db there were a bazillion tables named 'User_XXXXYYZZ' or 'Product_XXXXYYZZ' and so on and so forth.
Every first of the month, some poor asshole had to prepare for the 'billing cycle', that was used to send the invoices to the various customers to get the money. A task that was extremely important. This task started by running a script that scrubbed the db and generated an humongus .csv file that was then manipulated in Excel to be "cut" into pieces, each single piece was then re-manipulated to add discounts, specials and the like. This whole mess was then processed by another script that ended up generating a million invoices to be sent to a million customers.
As you can imagine, this procedure was slow, long and prone to go pear-shaped, especially in the last phase that was mostly manual modification. And the problem was that if something went wrong, the only way to repeat the whole thing was to restore the database to the point BEFORE the beginning, sinche the 'scrubbing' phase was creating a zillion new tables.
Somebody with some brain had suggested to $sales to use a 'retention' for the backup of at least 30 days, to be able to get back to the previous month in case of problems.
And we get o a nice day, when $sale opened an "urgent" ticket to ask the restore of the db to 2 month before. Our CL looked at it, and replied that the retention was only 30 days so it wasn't possible to do the restore. And then he closed the ticket faster then Lucky Luke.
20 seconds later the phone start ringing. And at this point the problems begins, because $sales pointed out that the if the 'retention' is 30 days and today is the first of March, then should be possible to go back to the 30 of January (since February is only 28 days). And mathematics agrees.
However, I couldn't fail to notice that the snapshot aint't there anymore. In fact... THERE ARE NO SNAPSHOT for the customer. What the fuck? Clearly the thing (and the mails sent by $sales to everybody) attract DB's attention.
So I start looking at the "backup" script and found that... the script should compute the $dayoflastbackup = $today - $numberofdaysretention, but apparently, the CL that wrote this things wasn't good at using DateCalc, so he resorted to $dayoflastbackup=$firstdayofthemonth. Watch out: $firstdayofthemonth, not $firstdayofthemonthbefore. This means that the first day of the month, everything before is zapped.
And that's why the backup is only the first step, you also have to test it.
Davide
23/04/2019 15:56
) con un'unità di backup in grado di gestire quelle cartucce.
