SMBs? Are you big enough to have a serious backup strategy? One of the TLAs* we come across all the time in IT is CIA. It's not, in this context, a shady American intelligence force: as far as we're concerned it stands for Confidentiality, Integrity and Availability – the three strands you need to consider as part of your security and data management policies and processes. Most …
> There's one drawback with the infinitely-incremental backup approach: it's non-trivial to throw away old data, because all but the first backup have to refer to that first data dump in order to work.
The approach taken by rdiff-backup (open source) is reverse diffs so that the most recent backup is always stored in full (and in the clear) and older backups are recovered by reconstruction from incremental (compressed) diff files.
This makes it easy to remove older backups (--remove-older-than). It also means that corruption of your backup data (e.g. one incremental backup file gets wiped) is more likely to damage older backups and less likely to affect the most (or more) recent; the opposite is true for conventional forward-diff backup approaches. Most of us would prefer to lose the backup from last year rather than the backup from last week.
It seems to hit a great many spots that need hitting. Thank you. Most of it won't be new to people who've played this game for a while, but e.g. it's still surprising the number of people who confuse replication (or RAID) with backups.
Might have been 9 out of 10 if there'd been a sentence or two going into a bit more depth on the conflict between "don't tidy up old stuff, it's cheaper to buy more storage than spend time sorting what you want from what you don't" and "do tidy up old stuff, not only for space but also in case it's got stuff you don't ever want revealed".
In order to make it work with tapes, you keep a database of all of the backed-up objects, so you don't need to look at the tapes all the time. In fact, what then determines the storage technology is how fast you need to restore your clients, not how you back them up.
Using a database makes it possible to have an incremental-forever method, although identifying duplicate objects is a bit difficult unless your database contains not only modification time and date info, but some unique hash of the backed up object. But it does allow expiry controlled archive as well as backup operations in the same solution.
Established traditional high volume backup solutions still work well with flash, disk, tape, and even worm devices, although they are generally not cheap.
I find that it's best to start with WHY you are backing something up.
In normal operation, with everything sunny and happy, backups are usually irrelevant. So the question is: what potential situation or request are you trying to resolve by recovering a backup?
When it comes down to it, there are three main reasons to back up data: recovering lost/changed data, recovering lost infrastructure (from a server to the entire building) and archive/data discovery.
Some backup solutions can work for all three but each of the scenarios have different priorities and requirements such that a system that covers all of them is likely not the best fit for any - or at least only for one.
For example, some data may need to be kept for several years but this is usually only a small subset of total data and infrastructure. Using whole server backups to fulfill this function is fully possible but keeping weekly backups of an entire server image for 7 years is going to cost you rather a lot in storage.
As another example, backups for the purpose of disaster recovery should be kept offsite, but this is inconvenient when one wants to restore a file that was accidentally deleted. This might not be a big issue with a larger company that has the budget for an offsite location with a fast link where the backups are held but for smaller businesses, they will more than likely be relying on external hard drives for disaster recovery purposes and thus 'offsite' means inaccessible unless specially retrieved.
So, when if comes to small businesses, the best way to approach things is to split it all up into these different purposes and figure out the best solution for each. Depending on the business and their budget, it may be that two birds may be accounted for with one stone but other times, three separate processes covering the three requirements can work out cheaper and more reliable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
