Back up your data!!! (or, The Disaster That Wasn't) - 2 minute read


This is your data:














This is your data without a backup:



Any questions?

This is especially important in programming because your data is your work product.

Seriously - back up your data.  Frequently.  And keep an offsite copy.  I saw this first-hand this last week: my experience as a server administrator made me realize the need for quick system-level recovery, so during the web development course I'm in I wrote a bash script that:

  1. Runs a git command to track all changed files.
  2. Runs a git commit.
  3. Runs a git command to send that commit to GitHub.
  4. Runs a TimeMachine backup.
This gives me a TimeMachine restore point every time I make a git commit, and I only have to run one command to do four things (the syntax is at the bottom of the blog).

What I didn't know is that it would come in handy last week: last week was project week, which means that I was put in a group and told to build a full-stack application in four days.  On day two, the service that runs that lets me talk to my MongoDB database . . . . wouldn't run.  Period.

Aargh!

With zero time to troubleshoot (we only had four days to make the application), I did pair programming with a colleague for the rest of the day.  That night, in less than an hour, I restored my computer back to a time when it was working, worked some more on the project, and we got the project done on time.

For people who don't have a backup administrator:

Automate frequent backups.  It'll take a while to read up on it, but it'll save you time down the road:
Time Machine (Mac)  use tmutil from the command line to run a backup after setting it up

For people who have a backup administrator:
  1. Talk to your admin at least monthly.  Things change, and it's best if the backup team is in the loop.
  2. Ask how often you data is protected.
  3. Ask if your OS and application are supported by the backup software (be specific down to the service pack level).
  4. Ask if server-level or application-consistent restores are available.
  5. Ask if your database is supported by the backup software (be specific down to the revision / service pack level).
  6. Talk to the backup admins again BEFORE installing service packs or upgrading your database version.
If you do 1 - 6 above, especially #6, your backup admin will love you!!! There's no worse feeling for a backup admin than being told, "Yeah the development team just upgraded to (<this new software>) two weeks ago .. . ."  Because the panicky klaxons of "Man, is that compatible with our software?" will immediately sound off in his or her head.


Syntax for automating commits, uploading to GitHub, and backups on a Mac (assumes you're on a git branch called 'dev'):
git add -A;git commit; git push origin dev; tmutil startbackup --auto



Comments

Post a Comment

Popular posts from this blog

Optional object property access

Image
  Photo by Hannah Joshua on Unsplash Options: they aren't just for day traders any more! I just read a post by Dr. Axel Rauschmayer about null and undefined ( link to article ).  Here's a summary of some of the more interesting items about optional object property access and the nullish coalesce operator. The ?. operator is equivalent to "if the property exists, return it else return undefined". You can chain the ?. operator for nested objects: it will return undefined the first chance it gets. The ?? operator is like the `or` operator (||) except that it only passes through null and undefined. Examples: The ?. operator is equivalent to "if the property exists, return it else return undefined". let obj = { foo: 42 }; obj?.address // undefined obj?.foo //42 You can chain the ?. operator for nested objects: it will return undefined the first chance it gets. let users = [     { name: 'Tom', address: { line1: '1234 Main St.', line2: { city: '
Read more

A short guide to cross-site request forgery attacks

Image
Photo from Negativespace . This is a follow-on post to my post on clickjacking attacks . I found this article from Auth0 ( https://auth0.com/blog/cross-site-request-forgery-csrf/ ) while reading the one on clickjacking.  As before, it's worth reading.  Here's a summary. What CSRF attacks are CSRF, aka "c-surf", is an acronym fro Cross-Site Request Forgery.  The attack is where a malicious site uses another site's active session cookie to do something in the place of the user.  E.g. if you're logged in to your bank and go to a site in another browser tab, the other site could use the bank site's active session cookie to transfer money. How to prevent them User Log out of websites, especially sensitive ones. Back end The article and OWASP do a good job of explaining the details, so I'll link to them here and give an overview. https://auth0.com/blog/cross-site-request-forgery-csrf/ https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_
Read more

How is an application like a bride's outfit? - 1 minute read

You've heard the tradition of a bride wearing "something old, something new, something borrowed, something blue."  Well, that's somewhat like a good piece of code.  Here's why: Something old: code you've already written (don't repeat yourself) if you can. Something new: customize the old framework. Something borrowed: similar to the 'something old', if you can find code that someone else has already written and has shared, use it!!  Libraries were written to be used! Something blue: OK, I admit this one is more of a stretch than the others, but bear with me: in this case, 'something blue' is to make something really useful for the user . . . and that starts with character!  Your users will use your application if it's easy to use and solves a problem, but they won't love it unless it's entertaining.  Caveat: Clippy  is proof that this last point needs to be taken with a grain of salt: sometimes, applications are better of
Read more