GIT Repositories for Clients

General Help
1

I back up my source to

  1. A USB Key (once a month),
  2. USB hard disk dozens of times a day
  3. GIT repo on my hard Drive (dedicated to GIT repos)
  4. Mirrored to GIT on my NAS box (the disks on the NAS box are mirrored to NAS box owned by a friend)

As you can see, I don’t trust anything.

That’s fine for me. But I am now thinking of the client, especially since we need subcontractors).

I would like to mirror just the project source to another “GIT server”. What do others do in this case?

  1. I could set up a Cloud server of some sort on AWS
  2. Or I could install GIT on the AWS windows server that I have set up for the client. It runs the new website and REST servers.
2

If you have a fire, flood, or a similar disaster or are robbed you potentially lose everything.

So you are trusting Mother Nature, and Mother Nature can only be trusted to be untrustworthy.

You are trusting your current setup and if I was carrying out a compliance audit, you’d fail. Sorry.

Get some form of cloud service. Today. In fact get more than one, from different providers. Also… today. Protect it however you want but work on the assumption that one method of 2FA is a single point of failure.

Feel free to argue this point and I will lay out the various lessons learned over the course of 42 years of dealing with things that should never happen, happening.

3

Funny how you say “Trust the cloud”, and then “various lessons learned …. dealing with things that should never happen, happening”.

Nothing wrong with a belts and braces approach, but yeah, at least one of them needs to be ‘remote’.

(Mainframe days, if the next two don’t seem to make sense to youngsters)

Reminds me of the, well known, company in Sydney whose data centre was on the 22nd floor of a building, so they stored their offsite backups in the basement.

Or another one in Florida, whose data centre was in one location and their ‘disks’ in another. For recovery purposes they had disks and computer in ‘the other’ location. Doubled the probability of a disaster, at least, but they felt it was their best solution.

Lots of those companies in the states had rules about key staff never flying on the same flight, and things like that. Make you laugh when you hear about companies using excuses of a similar nature to ‘get out of jail free’ when they make a massive stuff up. Most recent example being where both staff with the ability to fix a problem were ‘rostered off’.

4

Hi Ian,

Thanks for your thoughts.

I was after more specific info such as B2, S3, github, bitbucket. Especially for the client owned one. I will need to set it up and then pass ownership to them.

5

I didn’t say trust the cloud I said, trust multiple cloud providers. There’s a difference. I also said that he should choose them himself rather than I suggest them.

Having zero offsite backups, except for a friend who presumably lives in the same area, and therefore is also a subject to things like storms, wildfires, flooding, is probably not a good idea is it?

Nothing is certain, and I said that quite clearly, but one thing is certain, having things offsite, and in the cloud and spreading the risk is obviously a good idea.

6

I use Backblaze for cloud backups of home computers.

Oh, you also left out “Full rotating copy to offsite physical storage” from your regime, eg portable HDD stored away from home, rotated on a schedule.

It’s not possible to have too many backups. :slight_smile:

7

Thanks, I will have a look.

I ended up setting a private organisation github for the client.

8

100% fact. One day I must recount the story of what happened in the 1980s when I was an IT Manager for a large international company - and after a major outage we went to restore the data only to find all our backups were magically erased despite being automatically verified and stored in the local bank.

It was an interesting few days at work.

The '80s was a wild time to be in IT :laughing:

9

We had the same situation at a company called Datacom (I think it was called) back when they processed all the transactions for NZ banks. I had a friend working there on night shift (who used to use me as a ubereats driver). His main job was to create backups on magtapes. But no one had ever tested them, until they were needed. :rofl:

10

The '80s was a wild time to be in IT :laughing:

Indeed, the company I worked for (an insurance company), had a relatively modern IBM System 370 mainframe, but ancient 2400 series tape drives (9 track 1600BPI) from the System 360.

By 1980, the tape drives were about 16 years old, the bean counters upstairs deemed them to be still working and thus continuously knocked back the CAPEX to replace them with 3420 drives from the System 370 (6250BPI and significantly faster).

The 2400s might have worked but datachecks on write, not discovered until attempting to read back were becoming quite frequent.

The main database was on tape (as were all databases larger than about 20MB) and there were 30 generations of the database kept, before one got into the monthly copies.

Because they were tape based the daily updates were performed by merging the daily updates into the database. This had the added advantage of verifying that the daily updates could be read.

One day they had a datacheck on the current database, and had to go back to the second oldest generation before they could read the file. The database at that time was about 2 and a half tapes long, and took ages to read, as you can imagine. People were on the edge of their seats in the machine room hoping and praying for a successful restore. The programmers were frantic by then as recovering from a monthly copy was not something they were looking forwards to, as it pretty much meant reprocessing every days work, not to mention getting the keypunch girls to recreate the daily CMC tapes, as the old ones would have been reused pretty much the next day.

Of course that was, finally, enough for the CAPEX to get approved.

As the old drives were being disconnected an engineer noticed a perished rubber band wrapped around a relay. He checked the service manual for the relay’s function, it was the ‘Write’ relay. Checking through the control units service book the discovered that the drives had been suffering from intermittent write problems 12 years earlier which the engineer had tracked to a ‘lazy’ relay, which he had temporarily fixed by putting a rubber band around it. Somehow a replacement relay had not been installed.

I suppose we were lucky that the ‘modern’ engineers didn’t like playing with old control units with relays in them, otherwise they probably would have repaired it and the CAPEXs would have continued to be rejected.