Tag: backup

Nov 15 2017

Backing Up Your Stem Cells

The science fiction of the last 30 years is rapidly becoming reality as technologies such as virtual reality and artificial intelligence are becoming more real and present with each passing day. While my jetpack still seems ponderously far away and cars are becoming self-driving instead of flying, we are making progress.

In medicine, progress is methodical and incremental. As lives are literally at stake, it’s imperative to move forward in a logical and data-driven manner. The resulting regulatory requirement of clinical trials may sometimes be seen as an innovation-stifling burden, but lengthy clinical trials protect patients by ensuring safety and efficacy of therapies. The result? As real advancements are being made in biotechnology, such as engineered cells to fight cancer or using stem cells to regenerate the spine, news and hype eventually quiets during decade long timeline for these technologies to clear trials. There is a bright horizon of therapies that many of us are unaware of.

While I’m not a biotech investor, I ran into a company in Techstars Class 92 (Seattle 2017) called Silene Biotech that fascinated me. The founder, Alex Jiao, has been focused on regenerative medicine for the past decade, an area of research that still feels strongly like science fiction. The idea is to use our cells outside the body to regenerate or regrow lost tissues and organs. A buzzword in this space is “stem cells” and nowadays most people are familiar with the general concept. Stem cells can self-renew and turn into other cells, so their potential is incredible for regenerative medicine.

Currently, there is a lot of mythology and misinformation surrounding stem cells. Unlike newts which can regenerate their limbs, our bodies have limited repair mechanisms and our stem cells can only do so much. However, there are businesses purporting that a simple injection of unmanipulated stem cells can work miracles. The FDA disagrees, and without any compelling data from a clinical trial, most scientists would disagree as well.

I learned from Alex that not all stem cells are the same. Different stem cells have varying abilities to regenerate and turn into other tissues. Furthermore, we are also realizing that it takes guidance and manipulation to coax a stem cell into the correct cell or tissue for regeneration. And new technologies allow us to reprogram adult cells into more “potent” stem cells. These factors have now led to stem cell-based clinical trials to treat diseases such as macular degeneration and heart disease, with some early promising results.

There are still limitations to stem cell technology. One major limitation is that we are realizing age and environment can have a profound effect on stem cell function and even safety. Essentially, the older we are, the older all of our cells (including stem cells) become, and as a result, our bodies’ natural repair mechanisms deteriorate or stop.

Given these factors, I was excited about Alex’s notion that “backing up” our cells and stem cells could be a valuable tool for improving and extending our health in the near future. We can stop the biological aging of our stem cells by putting them in a deep freeze at an earlier age, when they have fewer mutations and damage. Banking our stem cells will then allow us to eventually generate and bank other tissues for self-use, like a population of heart cells for cardiac repair or a population of liver cells to diagnose drug toxicity. As technology moves towards a future where it’s technologically possible to engineer tissues and organs from our own stem cells, backing stem cells up today can give us the best opportunity to use them when we need them.

I love the idea of backing up my stem cells. Alex and his team are coming to Boulder to do this for me on 11/29. If you are interested in backing up your stem cells, Alex has offered to do it for a few others in Boulder when he is here. If you are interested, just email me and I’ll connect you with Alex.

Comments
Jan 3 2016

Accidentally Deleting Everything

The first time I experienced someone accidentally wiped out a full set of data was on an IBM PC with a Tallgrass  Hard Drive and Tape Backup. I was at PetCom Systems, my first real job. It was a Friday evening and I was the only person around. The phone rang and I answered it, “PetCom Systems, how can I help you?” It was a user from somewhere who was trying to back up for the weekend and didn’t know what to do next. I asked her what she had done. She walked me through what was on her screen, which basically said “Are you sure you want to delete all the files on your disk.” She had already pressed Enter in a panic, it had finished whatever it was trying to do, and her PetCom software (and nothing else) worked anymore. She had somehow, from within Tallgrass, wiped out all the files (except for DOS) on her drive when she was trying to make a backup.

I told her what I thought had happened. I was 17. She cried. She told me her boss was going to fire her when he found out. She cried some more. I tried to say something soothing but I didn’t really know what to say. She eventually stopped crying, told me thanks for trying to help (I think she knew I was 17) and we said goodbye.

I went into the bathroom and threw up.

Since that time, I’ve typed some version of del *.* and answered Y more times than I’d like to think. I became good friends with Norton Unerase. After deleting the wrong directory a few times in the mid 1980s, I started always typing the full path name when I wanted to delete a directory. After doing this wrong a few more times and having MS-DOS eat files I wanted, I started making a backup before I deleted a directory. At some point I became pretty paranoid about backups.

And then I got casual again. About five years ago I decided I didn’t really care about any of the data that I had and if it all went away, I’d be fine with that. Fortunately, I’m not responsible for any data at work so I can’t really do any harm there. The only data that really matters to Amy are her photos so I’m extra careful with them (and have plenty of backups).

As I started down the Great Photo Organization of 2016, I made a backup. Yay. As I fell in love with Mylio, I gave myself the illusion that it was backing things up correctly because of its “Protection” approach.

Early yesterday morning, I set up Mylio on Amy’s computer, feeling ready to get her rolling with it now that I had organized 22k+ photos and was very happy with them. I installed Mylio, set it up, pointed it at the photo directory, and hit Enter. It did something different than I thought it would (and that it had done when I added on my second computer – or at least I think it was different.)

I then tried to set it up correctly again, the way I wanted. It created a second photos folder in Amy’s instance of Mylio and started adding all the photos to the library again, doubling the photo count. I highlighted the first folder in Mylio that I had set up and hit delete. I told it to only delete from this local computer. However, I’d pointed it at the Dropbox file share of our photos.

Two minutes later as one folder was counting up and the other was counting down, I realized I’d fucked myself. My heart rate and blood pressure went up and a giant “Fuck, fuck, fuck!” emerged from my lips.

It took me about ten minutes figure out what state things were really in and how bad it was. I knew I had a backup pre-organizing folders, so my worst case was that I lost four hours of moving files around from folder to folder. Mylio grinded away for about 30 minutes synchronizing all machines to the same state, which was one where there were no photos anywhere.

Amy said soothing words to me during this stretch of time. She had only asked me 351 times the previous few days if all her photos would be ok, so I put her behavior in the heroic category. Heroic calmness. “I feel bad for Brad” was soothing said by her, instead of “You fucking asshole – you deleted all our photos!” which would have been appropriate for her to say.

After everything settled down, I went into Dropbox, clicked on Deleted Files, and clicked on Restore next to the folder that said “Photos.” Dropbox is happily doing its thing, giving me back the four hours I might have lost.

Dropbox wins today. You get huge karma points for saving my bacon without me really deserving it. Thank you.

Mylio – you need to clean up a little of the UX around Dropbox.

Brad, ok, you’ve blown it once – be more careful now.

Comments
Jun 15 2012

Megaupload and the Future of Multi-tenant Services

This is a post by Dave Jilk, a long time friend, business partner, and CEO of Standing Cloud. While the words are his, I agree 100% with everything he is saying here. I continue to be stunned and amazed by both the behavior of our government around this and the behavior of “us” (companies and individuals) around their data given our government’s behavior. But Dave’s point is not only around the actions of government, but the broader risks that exist in the context of multi-tenant services that I don’t think we are spending enough time thinking or talking about.

While I was in Iceland a few weeks ago, there was a set of discussions driven by Brad Burnham of Union Square Ventures about trying to make Iceland and “Internet Neutrality Zone” similar to Switzerland and banking. While I have no idea if this is feasible, the need for it seems to be increasing on a regular basis.

I encourage you to read Dave’s post below carefully. While neither of us are endorsing or defending Megaupload, it’s pretty clear that the second order impact and unintended consequences around situations like the government takedown of it have wide ranging consequences for all of us. And – it’s not just the government, but mother nature and humans.

Suppose you live in an apartment building, and one day the federal government swoops in and takes control over the building, preventing you from entering or retrieving any of your belongings. They allege that the landlord was guilty of running a child prostitution ring in the building and, while you are not accused of any crime, they will not give you access to your property. They suggest that you sue the landlord to get your property back, even though the landlord no longer controls the property.

This seems like a fairly obvious violation of your rights, and it is unlikely that the government would be able to maintain this position for long. Yet this is exactly what it is doing in the Megaupload case, and in relation to the rather lesser crime of copyright infringement. Somehow – perhaps because of the pernicious influence of large media companies on the government’s activities – rights to your digital data are taking a backseat to any and all attempts to enforce the copyright laws. This is what the online community was trying to prevent with its opposition to SOPA/PIPA, and the government seems to have elected to implement a de facto SOPA by simply trampling on the Constitution.

While I could rant further about the government’s egregious behavior, let’s talk about the practical implications of this situation. The primary implication is that there is a new risk to your data and your operations when you use multi-tenant online services. Such risks have always existed: if you do not have both an offsite backup of your data and a way to use that backup then any number of black swan events could disrupt your operations in dramatic ways. Earthquakes, wars, power brownouts, asteroids, human errors, cascading network failures – yes, it reads like the local evening news, and though any one situation is unlikely, the aggregate likelihood that something can go wrong is high enough that you need to consider it and deal with it.

What this particular case illustrates is that a company that provides your online service is a single point of failure. In other words, simply offering multiple data centers, or replicating data in multiple locations, does not mitigate all the risks, because there are risks that affect entire companies. I have never believed that “availability zones” or other such intra-provider approaches completely mitigate risk, and the infamous Amazon Web Services outage of Spring 2011 demonstrated that quite clearly (i.e., cascading effects crossed their availability zones). The Megaupload situation is an example of a non-technical company-wide effect. Other non-technical company-wide effects might be illiquidity, acquisition by one of your competitors, or changes in strategy that do not include the service you use.

So again, while this is a striking and unfortunate illustration, the risk it poses is not fundamentally new. You need to have an offsite backup of your data and a way to use that backup. The situation where the failure to do this is most prevalent is in multi-tenant, shared-everything SaaS, such as Salesforce.com and NetSuite. While these are honorable companies unlikely to be involved in federal data confiscations, they are still subject to all the other risks, including company-wide risks. With these services, off-site backups are awkward at best, and more importantly, there is no software available to which you could restore the backup and run it. In essence, you would have to engage in a data conversion project to move to a new provider, and this could take weeks or more. Can you afford to be without your CRM or ERP system for weeks? By the way, I think there are steps these companies could take to mitigate this risk for you, but they will only do it if they get enough pressure from customers. Alternatively, you could build (or an entrepreneurial company could provide) conversion routines that bring your data up and running in another provider or software system fairly quickly. This would have to be tested in advance.

Another approach – the one Standing Cloud enables – is to use software that is automatically deployed and managed in the infrastructure cloud, but is separate for each customer; and further, it is backed up on another cloud provider or other location. In this scenario, there is no single point of failure or company failure. If the provider of the software has a problem, it doesn’t matter because you are running it yourself. If the cloud provider has a problem, Standing Cloud has your backups and can re-deploy the application in another location. If Standing Cloud has a problem, you can have the cloud provider reset the password for your virtual server and access it that way.

As long as governments violate rights, mother nature wreaks havoc, and humans make errors, you need to deal with these issues. Make sure you have an offsite backup of your data and a way to use that backup.

Comments
Jun 2 2011

Backing Up Your Google Apps Data

I find it endlessly entertaining that people say things like “I don’t need to back up my data anymore because it’s in the cloud.” These people have never experienced a cloud failure, accidentally deleted a specific contact record, or authenticated an app that messed up their account. They will. And it will be painful.

I became a believer in backing up my data when I was 17 years old and had my first data calamity. I wrote about the story on my post What Should You Do When Your Web Service Blows Up. I’ve been involved in a few other data tragedies over the past 28 years which always reinforce (sometimes dramatically) the importance of backups.

We recently invested in a company called Spanning Cloud Apps. If you are a Google Apps user, this is a must use application. Go take a look at Spanning Backup for Google Apps – your first three seats are free. It currently does automatic backup of your Google contacts, calendars, and docs at an item level allowing you to selectively restore any data that accidentally gets deleted or lost. I’ve been using it for a while (well before we invested) and it works great.

I’ve known the founder and CEO, Charlie Wood, for six years or so. Charlie was an early exec at NewsGator but left to pursue his own startup. I came close to funding another company of his in the 2005 time frame but that never came together. I’m delighted to be in business with him again.

Don’t be a knucklehead. Back up your data.

Comments