Skip to main content

Happy Friday! Let’s kick off 2022 with something helpful for everyone!

 

Have you got a tip/secret weapon that you live to use to better protect environments? Maybe it’s something to help the service desk keep tickets down, maybe it’s something that helps improve your accuracy when sizing a deployment, whatever it is share it below!

 

Anyone that reads my blog posts will know I’m a strong believer that backup frequency shouldn’t equal your RPO, you should under promise and over deliver. You can see more on that here:

 

 

I preach this to everyone. But my favourite trick to delivery an awesome recovery experience involves storage snapshots and file servers.

 

Commonly I see organisations backing up their file server daily or twice daily. But we all have seen those pesky shared spreadsheets that are used by many people all day amongst other use cases. There’s a huge amount of data change per day on file servers and there’s always an accident or two.

 

So my trick when the customer has a SAN that supports storage snapshots is to use them, as frequently as the customer wishes (30-60 minute schedules on average) and retain them for 24-72 hours.

 

The support/recovery teams now have the ability to jump into much more granular time intervals for file recovery in the short term, without causing any noticeable impact to production performance, and without having to actually backup at such a frequency for long term retention!

My tricky thing about backups is discover somethings bad about the virtualization environment.

Veeam One helps for this task and I discover so many things… Very old snapshot are more common that I’d like to see.


Prayer :)


Prayer :)

😆


joking aside, it used to be to check what replication mode their AD servers were running in. If not DFSR and still on old FRS then non authorative restores won’t work if I remember correctly. 


local non AD administrator server passwords.. i.e. do they remember them just in case domain controller unavailable, or network on the nic gets changed to public for whatever crazy reason.


This is more a DR thing, but I often recommend to store documentations and passwords offline together with an offsite backup or in a tape vault. Without both, a restore will be very complicated, if not impossible.

Edit: Well I just noticed that my post is similar to @Geoff Burke‘s. 😉


Prayer :)

:grin:


These two things are very tricky for me:

  • Encryption passwords always safe and reachables in case of needed.
  •  Enough storage space to do / safe what they wan tot keep

Test your restore-performance before doing it for a real restore! And: when you designed backup/restore for SAN-mode, nevertheless deploy a virtual proxy. It can save a lot of time if SAN-mode restore would not work as expected.


A hammer to destroy my phone and a backpack ready-to-go.


Comment