Posts

Showing posts from 2019

The Unofficial Backup Admin's Handbook Part 5

Onsite and Offsite Storage Alright, this is the beginning of where Backup and Recovery meets Disaster Recovery. Where is your data stored? Do you keep it in your datacenter? Your Office? Shipped to a Colo or a 3rd party storage? Replicated disk to disk? There are tons of options and they are determined by your company's needs and requirements. Onsite Why would you keep your data onsite? Simplest reason would be speed of recovery. Having the data on location removes the need for shipping medium or transferring over a WAN connection of some sort. This is used when you're less worried about a large scale failure such as a datacenter going dark, but more concerned with data corruption or disk failures. Data can be stored on any medium listed previously. Offsite Distances less than 60 miles are generally not considered valid Disaster Recovery sites, but storage of medium at those locations are still valid for quick recall of medium and still reduces the risk o

The Unofficial Backup Admin's Handbook Part 4

Storage Mediums So let's now cover the various different storage mediums out there and some of their attributes: Disk (non-deduplicated) - SAN or Local disks Hard disk storage (either spinning or SSD) available to a backup server as storage space. Images are stored in their original size from the backup client. Best used for short term storage (such as staging) with minimum CPU and memory overhead Costly for longer term storage Very fast backup and restore (as data can be stored in a nonlinear format) Can be replicated offsite for Disaster Recovery/Business Continuity purposes Higher risk of data loss due to server tampering or virus/malware corruption (varies by platform) Disk (deduplicated) - SAN or Local disks Hard disk storage (either spinning or SSD) available to a backup server as storage space. Images are broke up into blocks, "fingerprinted" to verify unique data, and only unique data is stored. All duplicate data is reduced to a single copy and

The Unofficial Backup Admin's Handbook Part 3

Schedules As the name implies, schedules dictate the frequency a particular backup operation occurs. They can be as short as minutes, or can span to years. The most common schedule frequencies are: Hourly Jobs that run with a frequency of a certain number of hours. Not commonly used for file system jobs,  they are know more for application backup jobs such as SQL transaction logs. Daily Backup job runs once per day. These are used for frequent jobs, such as an incremental you want to run everyday. They are also commonly used for more critical application backup jobs, such as a SQL database that you want a full backup of every day. Weekly Backup job runs once per week. This job is typically on the same day each week, and are commonly used to run larger backups. An example would be running a Full backup every Saturday. Monthly Backup job runs once per month, typically on a designated day, such as the first or last day of the month, or on a particular day, such as the first

The Unofficial Backup Admin's Handbook Part 2

What are the different types of backups? Generally, when we're talking about types, we're referring to the following: Full Backup A backup of the entire selected criteria, regardless of last backup date. This could be an entire set of servers, a selection of disks, Applications, or maybe certain files/folders.   This is normally performed less frequently as it is generally the most intensive type.  To restore data from this backup, you would simply need the one backup instance. Incremental Backup A backup of data that has changed since the last backup ran (notice last backup, not last full backup). These are generally performed when the rate of data change is moderate and the need to keep each backup as small as possible (either for backup size, time or both) and wouldn't mind it taking a bit longer to recover data. A full restore would require the last designated Full backup plus all Incremental backups that have occurred up to the loss.  Differential

The Unofficial Backup Admin's Handbook Part 1

What are backups and why do we need them? According to Merriam : a copy of computer data (such as a file or the contents of a hard drive) Notice it says copy. Not a snapshot. Not a replication (without versioning). Copy. The backup should be point-in-time, on different storage, and have an expiration. Think of it as insurance. Something you hope you never need, but are really glad when you do. What's the difference between a "backup" and an "archive": Backups are typically used to make a copy for a data loss situation. The information is typically maintained for a shorter amount of time. Archives are copies made for long term retention and in many cases the original data is removed upon completion of the archive job. These are used more often to maintain data for historical, legal or compliance purposes. Why are backups so important? Multiple studies have shown that many companies (some estimates as high as seven in ten small companies) tha

The Unofficial Backup Admin's Handbook

I've been discussing the topic of "what's involved with being a backup admin" and was encouraged to write up an unofficial "guide". This is NOT intended to be an end to end how-to setup your backup environment, but what would normally be common knowledge to those in the role of a Backup Admin. I may (and probably will) make recommendations or generalizations. Just remember, this is what has worked for me in my environments and my opinions. Ultimately you must review your requirements and tailor any solution to meet your needs. I'm committing myself to write up this multi-part post to further share the knowledge I've accumulated in the hopes of preventing someone else's headaches. I will try to stay as vendor neutral as I can so this information will be usable by a wider audience. As a note, all backup products do the same basic functions, just with different processes or terminology to achieve this. Regardless of product used, the gen

Ok, so I'm backing up using VMware APIs for Data Protection (VADP) - now which transport mode do I use?

Okay, so you just pulled your shiny "Backup Product  X" out of the shrink wrap or extracted the ISO to your system. You've installed the software onto your backup server and begin to configure a VMware backup job. You get to the part where it asks for your transport method. What's this? SAN? NBD? NBDSSL? HotAdd? Appliance? Why don't they speak English (or your local language of choice)? Easy there. Let's take a step back and lower the printer. You're not in Office Space. So let's break down the Transport Modes from earlier : SAN - Storage Area Network. You might be asking yourself "What? I can use my SAN for backups?" Sure, as long as you meet the following criteria: 1) Your Datastores reside on SAN attached storage (come on, that was a lob) 2) You're not using VVOLs or VSAN (Sorry, neither is supported by SAN transport) 3) You aren't backing up VMware Encrypted VMs (not to be confused with OS encryption or storage encr

My journey to vExpert and beyond(part 2)

Alright, so I'll fess up. I've been slacking on my posts. It has been a busy year and I feel I'm just getting my head back above water. Between work and two additional speaking sessions at the Cincinnati and Orlando UserCons, followed up with my VCP6.5-DCV upgrade/renewal, crazy barely describes it. I'd like to clarify what vExpert is to me. It's neither a certification nor an accreditation. It is an acknowledgement. A tip of the hat as it were. It is recognition of those with valuable knowledge and skills whom instead of hoarding it, share it freely with others to enrich the product, the community and the experience. It is know-how that could be sold, but is instead shared with only the request to "pay it forward" as the only form of compensation. That is the reason I see value in putting effort into the program, and it's appreciated that program partners choose to reciprocate by granting access to products we may not otherwise get a chance t

When could/should/would I use Guest level (agent based) backups?

I've recently read an article that listed "best practices" and one of the items listed seemed a bit like bad advice. Which one you ask? When it stated you shouldn't perform Guest Level backups of your virtual machines. Why would you ever want to backup from the guest instead of the hypervisor level? There are 4 cases I can think of right off of the top of my head: 1) Need to be able to perform granular recovery of files from a filesystem not supported by VADP. While the list of supported file systems is growing, some backup systems still have problems reading metadata from EXT4 and support only LVM2, but even currently filesystems such as BTRFS are still unsupported. 2) Backup of Fault Tolerant (FT) clients. Currently FT does not support VMware snapshots, which makes VADP backups a non-starter. Solutions recommended was to disable the FT during the backup and then re-enable it afterwards. To me this seems unnecessarily convoluted and prone to any number of failur