Tag Info

Hot answers tagged

27

First: When the server room becomes a building site, you must remove all the servers, for several reasons. power outages cooling outages access (you dont know who walks past your servers, on what hour) mechanical stress due to building machinery direct damage by workers who go bump residual dust from the building site, especially metalic or mineral dust ...


21

Get all the technicians in. Make them check/clean all the equipment. Send the bill to the building planner. Really, servers can withstand some level of dust but this is just too much. We clean our servers regularly during downtime with a PC vacuum by 3M. It's a nice thing to have around the office. But for now, start cleaning. The faster you get the ...


21

http://www.storagesearch.com/disklabs-art3-floods.html Do NOT attempt to recover the data yourself. This will do more damage to your data and makes it more difficult to recover when it eventually gets to a data recovery specialist. When hard disk drives get wet, the 'heads' can get stuck to the platters. When the hard drive is powered ...


20

A couple of jobs ago, one of the datacenters for the place I was working for was one floor below a very large aerial. This large, thin, metal item was the tallest thing in the area and was hit by lightning every 18 months or so. The datacenter itself was built around 1980, so I wouldn't call it the most modern thing around, but they had long experience ...


7

First and foremost, boot off a live CD or recovery disk and back up your data. You may want to include system configurations from /etc, too. You can try doing a reinstall over what you have, leaving your partitions you want to keep untouched. As long as you weren't keeping your good data in any system partitions (and let's hope not under /usr), you should ...


6

It always comes down to how much you want to spend. I don't have deep enough knowledge to speak at length about this, but I've been in a big pharma datacenter that took a lightning strike and blew through something that was supposed to be a multiply-redundant spike arrester (and was designed correctly, but was implemented wrong so something got through.) ...


6

I've been thinking about this question since it recently got edited back to the top of the front page. I freely stipulate that, for people like sysadmin1138 who have to deal with installations that are highly-attractive to large lightning strikes on the DC roof, specific contingency planning for a big strike makes sense. But for most of us, this is a ...


6

Your options should be dictated by your service-level agreements with your customers and limited by your budget. At the very minimum, you should have off-site backups of all critical data. That is to day, any data which you cannot recreate from scratch needs to be stored elsewhere. Offline backups are better: online backups or replication might help when ...


5

My recommendations: Google "undelete for Linux", and you'll find something such as http://www.r-tt.com/data_recovery_linux/. You can use this to undelete any documents that you want to recover. Take a step to avoid this in the future. What you want is a method to make a copy of the partition, something like Acronis TrueImage for Linux. If you run Acronis ...


5

I am presuming that you are using Redhat simply because that is what I am using: Step 1- Since you shouldn't have any actual data store in /usr (man hier), you should be able to reinstall all the system binaries with: cd /root rpm -Va > filename rpm -qf `cat filename | awk '{print $3}'` | sort | uniq > filename2 yum reinstall `cat filename2` If you ...


4

First rule of data recovery: Stop using the disk Undelete is possible, as Gravitas suggests, but the more you use the disk, the greater the chance the freed sectors will be overwritten by new data. Even just log files on an idle, booted system can be enough to scupper your recovery chances. The recommendations above are good, but make sure you do them with ...


4

In general, no, there's no easy way to undelete files on most Unix filesystems. For specific filetypes (such as photos), your prospects are a little better; see this document, for example. This document talks about using the debugfs command to recover deleted files, but I don't know if this is applicable to ext4 (and as the article says, there's no ...


3

Undelete kludges can work if you've lost a file or two, but with such a large chunk of data removed, I don't think chasing that will be a productive use of time. The suggestions of copying over files from another system may get you back up and going, but may leave your system in an "impure" state, where not everything is back where it belongs. My ...


3

If you need as much as possible, take it to a specialist. The inside needs to be free of water and debris (even dust). It might need to be opened in order to dry out the platters. If that's the case, you shouldn't be doing it. Drives need to be opened inside a cleanroom. Dust on the platters is very bad news. If you don't have the budget for a real data ...


2

Yes, yes I have and it can work just fine but your success all comes down to what's doing the DB/file quiescing and is it talking to the SAN controllers to syncronise the two operations. We tend to use a combination of Oracle 10/11 and some of the HDS bolt-on tools but I'm happy to help you if you let me know what DB/OS/SAN etc. you have or are looking at.


2

Try to install the very same distro (RHEL4, judging by the kernel) somewhere else and manually copy important binaries and libs under /usr. Try to get a list of installed packages by rpm -qa (rpm is under /bin, and lists and variable stuff is kept under /var so this may work to a some extent). Reinstalling from scratch would be a best option, but if it is a ...


2

Business Continuity goes much, much further than just making sure you've got access to readable backups. But confining the scope of the answer to just that, ultimately it's only going to be viable where the end-to-end bandwidth from the datacenter to the backup location is sufficient large to handle the volume of data changes. When you're talking about a ...


1

We have a number of separate active/active or active/semi-active data centres with >50 miles between them, different power suppliers, security, diversely-routed 10GBps meshed links between them, oh and we ship our backup disks between them too. This does for us.


1

We have a VPN from our office to our offsite datacenter. At the offsite datacenter we have server that has a network share mounted that we configure as a destination in our backup software (we run Symantec BackupExec) i.e. \OFFSITEDATACENTER\OFFSITESTORAGE We then do - a full backup over the weekend to that location - an incremental each evening As well ...


1

You can copy the the whole /usr directory from the other same h/w and configuration server or machine. It will work. But just make sure you make the symlinks as we


1

On top of the preservation-advice by Josh, do keep in mind data recovery companies will usually charge per file/byte and time spent. If you can clearly map out what files you absolutely need and how the disks were structured (raid, filesystems, ..) you can keep the costs down. Squeeze everything you can out of your backups and see what data can be easily ...


1

Putting the hard drive in an airtight container with uncooked rice should help to absorb the moisture. Edit: further enlightenment suggest this could be risky because of the residue left by contaminants in the water. Therefore, there are a few options: hand the drive over to a specialist wash it with clean water before dying it dry the drive as it is


1

By default the SMTP virtual server in Exchange has a message expiration setting of 2 days (48 hours). When the expiration time is met the messages are deleted from the queues. As far as I'm aware there's no file system interface for the outbound email queues. Here's a nice article on mail flow through Exchange: ...



Only top voted, non community-wiki answers of a minimum length are eligible