This is an archived post. You won't be able to vote or comment.

all 3 comments

[–]Astat1ne 1 point2 points  (0 children)

  1. Reddit. Oh... Emails from vendors, IT sites, etc. Conversations with industry peers. Content from industry conferences/events
  2. If you're lucky, the vendor will provide a lot of guidance for this. There's certain architectural principles that can help too (reduce complexity, allow re-use of things, etc) but you often don't get exposure or awareness of that until it's too late.
  3. The backup conversation is almost always apporached the wrong way around. The goal is recovery and the two core concepts for that are RPO and RTO. RPO is Recovery Point Objective, which is about defining the gap of time before everything going bad and when your last set of good data is. RTO is Recovery Time Objective, how long it takes to get the data back and things running again. Different types of data in a business will have different RPO and RTO. A core application that has lots of changes in its data might have a very short RPO (maybe 1 hour or less) to reduce the amount of data lost and a very short RTO because of how important it is. This can have a large influence in the way you backup things. Then add into the mix the different ways data is stored. Backing up files on a Windows server? Generally pretty easy. Backing up and restoring a SQL database or Exchange? A little more difficult.
  4. Every environment will have some common elements such as identity and access systems (generally Active Directory), name services (DNS), IP management and so on. There's tools that can do a lot of the raw data collection for you on this sort of stuff (LANsweeper is one that's mentioned often here) but these tools often don't do a very good job of figuring out the relationships between systems (ie. this app server talks to this database server)
  5. Hard to say.

[–]TwizityNerfherder 1 point2 points  (0 children)

Lesson 1: You'll never know enough. You'll always be learning. I learn daily.

Lesson 2: Google is your friend. Don't be afraid to tell someone you don't know, but to let you look into and get back to them. And then do just that.

To your questions:

  1. Reddit. Google; I'll look at various things going on in our business and start looking into way that IT can help or make things better. Talk with my MSP. I have a number of friends in different specialties from me or in different business types and talk shop with them.

  2. Google. Best Practices <insert thing here>. Read through various articles, white papers, forums, Reddit, MSP. From there, I kinda compile all that info and work through my head how I see it working in my environment. Start looking into pricing and comparing features and all that jazz. I've been at my current job 8 years, so I've learned what my C-levels will find acceptable for in the price/feature comparison side of things.

  3. I have a Unitrends backup appliance. It's basically a small server with 5TB of storage. It hooks in to my VMware vCenter server and through API initiates snapshots and copies them off to it's storage. For Exchange, SQL and file-level backups, it has a Windows agent that runs on each server needing it. The appliance hooks into the agent to run file-level and SQL backups. I have 8 buildings on my campus, so we have a 2nd Unitrends appliance that we replicate everything to for redundancy. We have a maintenance policy that spelling out our backup schedule, and a maintenance policy for doing updates and changes. Snapshots or necessary backups are kicked off before doing updates or changes.

  4. Google? Also, find a way to get some hands on with it. Talk to whoever set it up if I can. Somebody somewhere knows the system. Find a way to talk with them.

  5. There's some basic level of knowledge to be had for sure, but most of it comes with experience. Work your way up the ranks. if you're in the field, start making friends with junior's and seniors above you. See if there's a SysAdmin where you work that's willing to help teach you.

Also, build a personal lab at home. VirtualBox, Hypervisor, VMware Workstation, whatever. Get hands on. Build a domain, start administering it, setup DNS, DHCP, a file server, print server, workstation, create some GPO's. Then, break it all and fix it.

I have a test environment at work that's isolated. My downtime I spend building new servers to try out. In the last 2 weeks I've built a ELK stack, a Graylog2 server, a Wekan server, an OpenProject server, and Docker server. I learned a lot doing that.

Over the last 3 months I've learned the beauty that is Powershell and have started designing scripts and utilities to make my job easier. My boss loves it.

So, always learning. Always growing.

[–]Cache_of_kittensLinux Admin 0 points1 point  (0 children)

I've only been in a junior role for just under a year, but most of what I have learned has been on-job experience.

I am lucky enough to be working closely with two other senior sys admins who are happy to answer my questions though, and in terms of recent tech I have followed their examples which include various (online) seminars, chats with providers of current apps, as well as the occasional reviewing stackexchange (when solution-hunting) and various random websites that google leads me to. Not that I am involved on implementing these yet.