Talking with Dmitri Joukovski, product management VP at backup firm Acronis, we were discussing backup and snapshots and I asked whether backup was still the best choice. He turned the conversation around and asked me what is backup? I said it was the collecting of the current set of files on a system, putting them into a single …
And before Acronis did snapshots, DEC did them with their StorageWorks stuff (either in hardware or software). And maybe others did too. So what?
A backup is something you can be confident you can restore files (maybe even a complete disk image) from. Everything else is marketing spin.
Horses for courses.
There are 4 main types of data backups with different advantages:
1) Snapshots - its space-efficient (practically free) but suffers from a single point of failure. Works as a backup to an extent. Can also be used to create forks in the work flow.
2) Adjacent (or near line) data backup & archive. This is a "semi-cold" backup-cum-archive requiring physical copies of the entire dataset. Usually disk based. Typically in the same physical location as the "hot" data. This allows "hot" data to sit on a performance oriented system without high level of data redundancy. Recovery is nearly instantaneous.. though depending on the solution there could be a short period of unavailability. Example would be a mail server which can move mails older than a month completely to the cold system (and may or may not backup recent mails to the archive storage). Is it really a backup ? depends on how its configured.
3) tapes for disaster recovery:. Done really for peace of mind/compliance... but not designed to be recovered from - except as an exception. If they are ever needed for recovery, usually the intermittent period suffers from low availability.
4) High availability from disaster: a parallel system in a distant geography which is kept in close sync with the active system. This typically doesn't involve tapes but a fat internet based pipe to keep remote systems in sync. The switch over can be instantaneousness, even though the remote site may lag by a few minutes to hours.
So while Arconis arguments have some water its not the full picture.
Paris, coz her tape was better than her snapshots.
Then came a kicker: "Snapshotting can be used for this and in no way contradicts the fundamental operation of backup."
Why is this a kicker? This reminds me of a conversation I had with a storage consultant just recently:
Him: "Snapshots and replication are NOT backups."
Him: "Well, you can't exactly take them offsite, for one."
Me: "But they are a point-in-time consistent copy of the data?"
Me: "And you can restore from them?"
Me: "And if your replication site is sufficiently separated from the main site, you can use it for disaster recovery?"
Me: "So how is that different from a backup?"
Him: "Hmm... Well... Umm... Well, my field is setup, not backup; you'd have to ask my backup specialist -- but I'm sure they're not backups."
So do we have a "backup specialist" here who can explain WHY snapshots and replication should NOT be considered backups?
What are backups for?
Providing one relatively recent copy of the data in question, to be used in case of hardware failure or catastrophic software failure? That's your DR site.
Or for providing multiple copies taken at multiple points in time, in case e.g. some corrupt data gets entered and you need to roll back to before that happened? That's NOT your (basic) DR site.
Hopefully you knew this, but lots of people don't. It's the same problem trying to explain the difference between RAID and backups to some people.
I'd agree, a snapshot is a backup, by definition.
However, if the snapshot is on the same physical device (a la shadow copy), it's not a very good backup against hardware failures (or flood/fire, etc.).
Also if you have some data that changes and some that doesn't, a snapshot is not a particularly efficient method for keeping a series of backups, whereas a snapshot plus deltas can be (IMHO)
I would link on to previous posts and add following summary: "Backup is point-in-time copy-of-data which you can separate and take away from existing systems. This copy-of-data must allow you to perform restores during the defined protection period."
This implies that the backup must NOT have any dependency on production systems. This is possible to achieve with snapshots, or replications, but there are some question you need to ask, or protect against, eg.:
(a) is there any chance that the replication will replicate the errors to my secondary/backup systems?
(b) does the corruption in any previous snapshots prevent me to restore data from later ones?
(c) how hard is it to recover failed storage device to original status?
Especially for replicated systems using snapshots were you plan to have redundancy of snapshot data cross DC. e.g. you have 100-generations of snapshots, are you able to recover the storage with all those 100-snapshots, or you will just recover to one of these "point-in-times" loosing all other snapshots on this recovered site?
There is no ideal solution for everyone, at the end everything is balance of technology limitations, business needs, price tag and supportability.
The main reason why good-old-tapes are still in the game.
This is news?
I've been using snapshots for my backups for years. This is not a big shop, and I've been doing it with VMWare GSX, Server (v1) and ESXi since 2003, with only a 1-year break to do it with XenServer last year.
Some funky scripting, and the whole thing just runs - take a snapshot, export it to a spool drive, stuff it on a tape (or onto the backup discs). Tapes come offsite. Easy.
Now, granted, I wouldn't want to do it with a large virtualised server farm. But big backups are where you need a backup specialist.
Your snapshots can't guarentee consistancy on an Application level. A snapshot, when started, acts like the power was cut to the server. If you had an MSSQL server in the middle of a series of transactions when you started the snapshot, you're likely to get data corruption. Fortunately, I believe snapshotting is smart enough to wait for (a) file-write(s) to fully complete first before drawing the line in the sand, but I wouldn't stake my business VMs on it.
Backups are good copies of your data, be it databases in a consistant state, or even files in a consistant state (you saving the word doc along with it's autosave hidden file too?), not to mention the Operating System in a consistant state. Snapshots are nice, when timed to hit during non-peak times, but I still wouldn't trust them on my SQL servers for "backups."
You're right to an extent
With ESX/ESXi you can tell it to flush the VMs' disc buffers at the moment of the snapshot, so at that point you should have all your transaction logs etc written to the snapshot. It's not perfect, no. But for the size of operation here it's pretty good.
I do file-level backups too, for what it's worth, but I also have clear off-peak times.
Best bet, as far as I'm concerned, is a weekly snapshot, plus a weekly file-level backup, plus daily diffs.
What you need....
....is an application aware snapshot! If only there was a storage vendor that had these baked in to OS, with software that quiesced the application in question, and provided the ability to replicate them off site, and vault them for long term retention....
By the way, I work for NetApp.. ;)
Having used Acronis software and had some experience of their help desk I wouldn't believe a word they said to me. I'd rather they fixed their software and responded to questions instead of arguing the differences between backups and snapshots.
Depends what you use the "backup" for,..
we currently hold processing until the nightly offline backup completes to allow rollback in case of corruption but are planning to introduce "bookmarking" technology on our SAN to create a rollback point which we can present elsewhere then backup, or else roll back to in case of corruption.
As this article highlights, you need to understand WHY you are doing backups, to look at viable alternatives of delivering the same end-goal. This is not something a lot of mangers are good at.
Snapshots, backups, and VMware...
We use snapshots on our SAN appliance for point in time backups, usually for restoring when our users make a 'whoopsie' of either their files or folders.
However, we also take a weekly tape copy of the SAN, which uses the same snapshot technology to make the backup process transparent to the user and to ensure consistancy in the data streamed to tape.
We tried doing backups of our virtual machines using VMware's backup tools and some glue code from our backup software (Commvault Simpana). it worked OK, until we discovered that the VMs were not taking the snapshot removal portion of it very well, which caused some interesting problems in our production environment.* We went back to the more traditional "install backup client on server, perform file back up" methodology for our VMs.
* In VMware, when you make a snapshot, it creates a delta disk file which it starts writing changed blocks to. removeing the snapshot commits those delta blocks back into the main file, which pauses the VM during that time. Depending on the size of the snapshot and how long it's been around, it takes anywhere from half a minute to several DAYS. VMware doesn't recommend having snapshots active on a production machine for more then 72 hours for this reason.
Are Snapshots Backups?
I tend towards the idea that snapshots aren't backups, I usually think of a snapshot as a point in time DR position, you may have many or only one. The key for me is that if I want a backup, I need to know that it's readable, this means that it needs to be read from the filesystem and moved by some software - which also indexes it - over a transport to its destination. A snapshot simply can't do this, a snapshot is a point in time block level copy of a filesystem, if there is a corruption on that filesystem, it is replicated into the snapshot, if the filesystem isn't properly quiesced, it's going to be have problems and you need to know about that.
Now, what I have done, many times in the past, is design systems which take a snapshot (usually an array based EMC BCV) and mount them up elsewhere to be backed up offline. This means that you've got a fast recovery point, but it's also checked when moved off to tape/virtual tape/disk etc.
Are Snapshots Backups?
When you back up something, you copy it somewhere else for safekeeping. That's sort of the point.
Taking snapshots is more like generating patches using diff - you still need the original for them to be useful. That's more like a journal or redo log, not like a backup at all.
Snapshots + off-site replication fixes that (indeed, my Bacula setup uses VSS to take consistent backups of Windows filesystems), but snapshots in themselves are not backups.
- Twitter: La la la, we have not heard of any NUDE JLaw, Upton SELFIES
- China: You, Microsoft. Office-Windows 'compatibility'. You have 20 days to explain
- Apple to devs: NO slurping users' HEALTH for sale to Dark Powers
- Is that a 64-bit ARM Warrior in your pocket? No, it's MIPS64
- Apple 'fesses up: Rejected from the App Store, dev? THIS is why