At one time, I felt that NAS had a rather distinct disadvantage. While it did significantly reduce system administration requirements, it created a challenge in one particular area - backup and recovery. Since most NAS filters usually involve a stripped-down version of the operating system, normal backup and recovery client software often isn't applicable. With a few exceptions, you can't simply buy client software from backup vendor for your filer. Although this has gotten better, there was a time when the only way to back up your NAS appliance was to use rump or to back it up via an NFS mount.
Even the advent of the network data management protocol, didn't seem to help things at first. It usually meant locally attaching a tape drive to a filer and backing up that server's data to that tape drive. This often meant a significant reduction in automation. It didn't help that software vendors were slow to support NDMP, because they saw it as competition to their own client software.
However, a lot has changed in recent years. All major backup-software vendor support NDMP, and you can even use SAN technology to share a tape library between your filers and your other backup servers. Even if you're backing up your filers across the network, gigabit NICs that offload the TCP/IP processing from the host CPU make data transfer over the network much easier and faster, Jumbo frames also helped some vendors.
Another reason that backup and recovery of filers is now less a problem is that some NSA vendors introduced data-protection options equivalent to the options available on many Unix or NT system - including built-in snapshots, mirroring, and replication. Therefore, for what it's worth, my respect for NAS has grown signigicantly in recent years.
Showing posts with label Backups. Show all posts
Showing posts with label Backups. Show all posts
Wednesday, January 20, 2010
Wednesday, October 21, 2009
What about NAS Backups?
At one time, I felt that NAS had a rather distinct disadvantage. While it did significantly reduce system administration requirements, it created a challenge in one particular area - backup and recovery. Since more NAS filers usually involve a stripped down (or significantly customized) version of the operating system, normal backup and recovery client software often isn't applicable. With a few exceptions, you can't simply buy client software from your backup vendor for your filer. Although this has gotten better, there was a time when the only way to backup your NAS appliance was to use rdump or to back it up via an NFS mount.
Even the advent of the network data management protocol (NDMP) didn't seem to help things at first. It usually meant locally attaching a tape drive to a filer and backing up that server's data to that tape drive. This often meant a significant reduction in automation. It didn't help that software vendors were slow to support NDMP, because they saw it as competition to their own client software.
However, a lost has changed in recent years. All major backup-software vendors support NDMP, and you can even use SAN technology to share a tape library between your filers and your other backup servers. Even if you're backing up your filers across the network, gigabit NICs that offloaded the TCP/IP processing from the host CPU make data transfer over the network much easier and faster. Jumbo frames also helped some vendors.
Another reason that backup and recovery of filers is now less a problem is that some NAS vendors introduced data-protection options equivalent to (and sometimes easier to use than) the options available on many UNIX or NT systems - including built-in shapshots, mirroring and replication. Therefore, for what it's worth, my respect for NAS has grown significantly in recent years.
Even the advent of the network data management protocol (NDMP) didn't seem to help things at first. It usually meant locally attaching a tape drive to a filer and backing up that server's data to that tape drive. This often meant a significant reduction in automation. It didn't help that software vendors were slow to support NDMP, because they saw it as competition to their own client software.
However, a lost has changed in recent years. All major backup-software vendors support NDMP, and you can even use SAN technology to share a tape library between your filers and your other backup servers. Even if you're backing up your filers across the network, gigabit NICs that offloaded the TCP/IP processing from the host CPU make data transfer over the network much easier and faster. Jumbo frames also helped some vendors.
Another reason that backup and recovery of filers is now less a problem is that some NAS vendors introduced data-protection options equivalent to (and sometimes easier to use than) the options available on many UNIX or NT systems - including built-in shapshots, mirroring and replication. Therefore, for what it's worth, my respect for NAS has grown significantly in recent years.
Friday, October 16, 2009
Preparing for the worst
One of the simplest rules of systems administration is that disks and systems fail. If you haven't already lost a system or at least a disk drive, consider yourself extremely lucky. You also might consider the statistical possibility that your time is coming really soon. Backup & recovery should be part of the disaster recovery plan,
My Dad Was Right
My father used to tell me, "There are two types of motorcycle owners. Those who have fallen, and those who will fall." The same rule applies to system administrators. There are those who have lost a disk drive and those who will lose a disk drive. (I'm sure my dad was just trying to keep me from buying a motorcycle, but the logic still applies. That's not bad for a guy who got his first computer last year, don't you think?)
Whenever I speak about my favorite subject at conferences, I always ask questions like, "Who has ever lost a disk drive?" or "Who has lost an entire system?". When I asked those questions there, someone raised his hand and said, "My computer room just got struck by lightning." That sure made for an interesting discussion! If you haven't lost a system, look around you... one of your friend has.
Speaking of old adages, the one that says "It'll never happen to me" applies here as well. Ask anyone who's been mugged if they thought it would happen to them. Ask anyone who's been in a car accident if they ever thought it would happen to them. Ask the guy whose computer room was struck by lightning if he though it would ever happen to him. The answer is always 'No.'
The whole reason of writing this post is to make you able to recover from some level of disaster. Whether it's a user who has accidently or maliciously damaged something or a tornado that has taken out your entire server room, the only way you are going to recover is by having a good, complete, disaster recovery plan that is based on a solid backup and recovery system.
Neither can exist completely without the other. If you have a great backup system but aren't storing your media off-site, you'll be sorry when that tornado hits. You may have the most well organized, well protected set of backup volumes, but they won't be of any help if your backup and recovery system hasn't properly stored the data on those volumes. Getting good backups may be an early step in your disaster recovery plan, but the rest of that plan - organizing and protecting those backups against a disaster - should follow soon after. Although the task may seem daunting, it's not impossible.
My Dad Was Right
My father used to tell me, "There are two types of motorcycle owners. Those who have fallen, and those who will fall." The same rule applies to system administrators. There are those who have lost a disk drive and those who will lose a disk drive. (I'm sure my dad was just trying to keep me from buying a motorcycle, but the logic still applies. That's not bad for a guy who got his first computer last year, don't you think?)
Whenever I speak about my favorite subject at conferences, I always ask questions like, "Who has ever lost a disk drive?" or "Who has lost an entire system?". When I asked those questions there, someone raised his hand and said, "My computer room just got struck by lightning." That sure made for an interesting discussion! If you haven't lost a system, look around you... one of your friend has.
Speaking of old adages, the one that says "It'll never happen to me" applies here as well. Ask anyone who's been mugged if they thought it would happen to them. Ask anyone who's been in a car accident if they ever thought it would happen to them. Ask the guy whose computer room was struck by lightning if he though it would ever happen to him. The answer is always 'No.'
The whole reason of writing this post is to make you able to recover from some level of disaster. Whether it's a user who has accidently or maliciously damaged something or a tornado that has taken out your entire server room, the only way you are going to recover is by having a good, complete, disaster recovery plan that is based on a solid backup and recovery system.
Neither can exist completely without the other. If you have a great backup system but aren't storing your media off-site, you'll be sorry when that tornado hits. You may have the most well organized, well protected set of backup volumes, but they won't be of any help if your backup and recovery system hasn't properly stored the data on those volumes. Getting good backups may be an early step in your disaster recovery plan, but the rest of that plan - organizing and protecting those backups against a disaster - should follow soon after. Although the task may seem daunting, it's not impossible.
Tuesday, October 13, 2009
The One That Got Away: True story of not taking backups
"You mean to tell me that we have absolutely no backups of paris whatsoever?" I will never forget those words. I had been in charge of backups for only two months, and I just knew my career was over. We had moved an Oracle application from one server to another about six weeks earlier, and there was one crucial part of the move that I missed. I knew very little about database backups in those days, and I didn't realize that I needed to shut down an Oracle database before backing it up. This was accomplished on the old server by a cron job that I never knew existed. I discovered all of this after a disk on the new server went south.
"Just give us the last full backup," they said. I started looking through my logs. That's when I started seeing the errors. "No problem," I thought, "I'll just use an older backup." The older logs didn't look any better. Frantic, I looked at log after log until I came to one that looked as if it were OK. It was just over six weeks old. When I went to grab that volume, I realized that we had a six-week rotation cycle, and we had over-written that volume two days before.
That was it! At that moment, I knew that I'd be looking for another job. This was our purchasing database, and this data loss would amount to approximately two months of lost purchase orders for a multibillion-dollar company.
So I told me boss the news. That's when I heard, "You mean to tell me that we have absolutely no backups of paris whatsoever?" Isn't it amazing that I haven't forgotten its name? I don't remember any other system names from that place, but I remember this one. I felt so small that I could have fit inside a 4mm tape box. Fortunately, a system administrator worked what, at the time, I could only describe as magic. The dead disk was resurrected, and the data was recovered straight from the disk itself. We lost only a few days' worth of data. Our department had to send a memo to the entire company saying that any purchase order entered in the last two days had to be reentered. I should have framed a copy of that memo to remind me what can happen if you don't take this job seriously enough. I didn't need to though; its image is permanently etched in my brain.
"Just give us the last full backup," they said. I started looking through my logs. That's when I started seeing the errors. "No problem," I thought, "I'll just use an older backup." The older logs didn't look any better. Frantic, I looked at log after log until I came to one that looked as if it were OK. It was just over six weeks old. When I went to grab that volume, I realized that we had a six-week rotation cycle, and we had over-written that volume two days before.
That was it! At that moment, I knew that I'd be looking for another job. This was our purchasing database, and this data loss would amount to approximately two months of lost purchase orders for a multibillion-dollar company.
So I told me boss the news. That's when I heard, "You mean to tell me that we have absolutely no backups of paris whatsoever?" Isn't it amazing that I haven't forgotten its name? I don't remember any other system names from that place, but I remember this one. I felt so small that I could have fit inside a 4mm tape box. Fortunately, a system administrator worked what, at the time, I could only describe as magic. The dead disk was resurrected, and the data was recovered straight from the disk itself. We lost only a few days' worth of data. Our department had to send a memo to the entire company saying that any purchase order entered in the last two days had to be reentered. I should have framed a copy of that memo to remind me what can happen if you don't take this job seriously enough. I didn't need to though; its image is permanently etched in my brain.
Thursday, September 17, 2009
Selection, extraction & backup of metadata from a PC
As we all all know that not every information of a Personal Computer is stored in data files, like some information gets stored in the CMOS, etc. So, the complete recovery of a system from its scratch requires the selection, extraction & backup of these as well:
- System description
A system description, or specifications, is needed to procure an exact replacement after a disaster. - Boot sector
The boot sector can sometimes be recreated more easily than saving it. Still, it usually isn't a normal file and the system won't boot without it. - Partition layout
The layout of the original disk, as well as partition labels, tables & filesystem settings, is needed to properly recreate the original system. - File metadata
Each file's permissions, owner, group, ACLs and any other metadata need to be backed up for a restore to properly recreate the original environment. - System metadata
Different operating systems have different ways of storing configuration information. Windows keeps a registry of system information that is more difficult to restore than a typical file, so a backup of the complete registry should also be kept so that it can be restored in case of a disaster.
Thursday, September 10, 2009
Findings of a global backup survey
A global backup survey, organized by Kabooza, about backup habits, risk factors, worries & data loss of home PCs came out with the following findings. The Kabooza survey was done on 4257 respondents from around 129 countries.
- 82% of home PC users don’t do regular backup.
- 66% have lost pictures & files on their home PC. 42% within 2008.
- 71% are most worried about losing their digital pictures on their home PC.
- 54% of the respondents do not have any backup what so ever for their PC.
- 54% of the respondents see virus as the primary risk factor for their personal data.
Tuesday, September 8, 2009
Notable incidents of not taking backups
There a few instances available where panic was created due to not taking timely backups. Three of such incidents are pointed below:
- In 1996, during a fire at the headquarters of Credit Lyonnais, a major bank in Paris, system administrators ran into the burning building to rescue backup tapes because they didn't have offsite copies. Crucial bank archives and computer data were lost.
- Privacy Rights Clearinghouse has documented [18] 16 instances of stolen or lost backup tapes (among major organizations) in 2005 & 2006. Affected organizations included Bank of America, Ameritrade, Citigroup, and Time Warner.
- On 3 January 2008, an email server crashed at TeliaSonera, a major Nordic telecom company and internet service provider. It was subsequently discovered that the last serviceable backup set was from 15 December 2007. Three hundred thousand customer email accounts were affected.
Friday, September 4, 2009
Why choose BackupDataOffsite.com?

The advantages of offsite data backups:
- Cost effective, secure and automated offsite backups
- Unlimited backup storage capacity at affordable, scalable rates
- Back up multiple computers to one account
- Schedule automated backups to run daily or even hourly
- Top-level security, performance and monitoring
- Easy to use software
- Install a small agent program on your computer or server
- Select files to back up, and a backup schedule
- Your files are encrypted and compressed, then sent to our data center
- Subsequent backups send only incremental changes, reducing bandwidth & backup times
- Receive email notification after every backup, or only when warnings or errors occur
Saturday, August 1, 2009
Methods of taking backup
There are many methods to take backup of your data. Most of the data is either saved in encrypted form or in compressed form. Some of the mediums on which data is stored are:
- CDs (obsolete now)
- Compact Flash
- DVDs
- Flash Memory
- Floppy drives (obsolete now)
- Hard Disks
- Magnetic Tapes
- Memory Sticks
- Pen Drives
- RAID
- Secure Digital Cards
- SmartMedia
- Thumb Drives
Why back up is important?
In any office the most important thing is INFORMATION. All our data, files, print outs, etc contain information that can be used to take decisions in any given condition or scenario. Large organisations such as banks, insurance companies, mutual funds, etc. interact with large number of people and store intricate information about people such as their financial information which can be crucial to there life. Another example is of large portals which keep the personal information of people stored within their databases.
Think of a scenario when suddenly due to natural calamity or fire the data gets deleted, burnt, destroyed or stolen. The people would blame the banks, insurance companies, mutual funds & portals for negligence & irresponsible behaviour.
To escape from such circumstances large organisations don't store data at just one place. They don't just store the crucial information at multiple locations but also at multiple cities or countries which enables them to keep the data safe & secure from such natural calamities or disaster.
The (crucial) data must always be stored safely & securely at multiple locations.
Think of a scenario when suddenly due to natural calamity or fire the data gets deleted, burnt, destroyed or stolen. The people would blame the banks, insurance companies, mutual funds & portals for negligence & irresponsible behaviour.
To escape from such circumstances large organisations don't store data at just one place. They don't just store the crucial information at multiple locations but also at multiple cities or countries which enables them to keep the data safe & secure from such natural calamities or disaster.
The (crucial) data must always be stored safely & securely at multiple locations.
Subscribe to:
Posts (Atom)