Showing posts with label Backup. Show all posts
Showing posts with label Backup. Show all posts

Friday, June 22, 2012

data deduplication

SkyHi @ Friday, June 22, 2012

Data deduplication (often called "intelligent compression" or "single-instance storage") is a method of reducing storage needs by eliminating redundant data. Only one unique instance of the data is actually retained on storage media, such as disk or tape. Redundant data is replaced with a pointer to the unique data copy. For example, a typical email system might contain 100 instances of the same one megabyte (MB) file attachment. If the email platform is backed up or archived, all 100 instances are saved, requiring 100 MB storage space. With data deduplication, only one instance of the attachment is actually stored; each subsequent instance is just referenced back to the one saved copy. In this example, a 100 MB storage demand could be reduced to only one MB.
Data deduplication offers other benefits. Lower storage space requirements will save money on disk expenditures. The more efficient use of disk space also allows for longer disk retention periods, which provides better recovery time objectives (RTO) for a longer time and reduces the need for tape backups. Data deduplication also reduces the data that must be sent across a WAN for remote backups, replication, and disaster recovery.
Data deduplication can generally operate at the file or block level. File deduplication eliminates duplicate files (as in the example above), but this is not a very efficient means of deduplication. Block deduplication looks within a file and saves unique iterations of each block. Each chunk of data is processed using a hash algorithm such as MD5 or SHA-1. This process generates a unique number for each piece which is then stored in an index. If a file is updated, only the changed data is saved. That is, if only a few bytes of a document or presentation are changed, only the changed blocks are saved; the changes don't constitute an entirely new file. This behavior makes block deduplication far more efficient. However, block deduplication takes more processing power and uses a much larger index to track the individual pieces.
Hash collisions are a potential problem with deduplication. When a piece of data receives a hash number, that number is then compared with the index of other existing hash numbers. If that hash number is already in the index, the piece of data is considered a duplicate and does not need to be stored again. Otherwise the new hash number is added to the index and the new data is stored. In rare cases, the hash algorithm may produce the same hash number for two different chunks of data. When a hash collision occurs, the system won't store the new data because it sees that its hash number already exists in the index.. This is called a false positive, and can result in data loss. Some vendors combine hash algorithms to reduce the possibility of a hash collision. Some vendors are also examining metadata to identify data and prevent collisions.
In actual practice, data deduplication is often used in conjunction with other forms of data reduction such as conventional compression and delta differencing. Taken together, these three techniques can be very effective at optimizing the use of storage space.

REFERENCES

Wednesday, June 6, 2012

How To: Transfer your PuTTY settings between computers

SkyHi @ Wednesday, June 06, 2012
PuTTY is tops on the short list of applications I install first on any Windows machine. Over the years I've used PuTTY, I've installed it on a huge number of computers but I've always had one complaint;There isn't a configuration file I can backup or move to a new machine

Getting all the little comfort settings correct for each SSH connection can be a pain. The third time you set emulation, keys, encryption type, etc. for each machine you regularly access, you lose patience. The fifth time you find yourself re-entering settings you might do what I did, find a better way. 

Moving PuTTy settings between computers is an easy task once you know what's involved. We'll find the registry keys where PuTTy stores its configuration information and export them to a file. We'll then use that file we've made to import our configuration on the target machine. 

Exporting Your PuTTy Configuration

Putty stores its settings in the Windows registry. To save a backup of your Putty settings, you'll need to export this registry key to a file. 

HKEY_CURRENT_USER\Software\SimonTatham

(Simon Tatham is the original developer responsible for PuTTy)

1. Click Start->Run and type "RegEdt32" in the "Open" dialog. Click "Ok"



2. One RegEdt32 starts, you'll be presented with an application which looks something like:


3. Press "Ctrl+F" to bring up the Find dialog. Enter the name of the key, "SimonTratham" in the "Find What" field, and make sure only "Keys" is checked in the "Look At" section of the dialog. Finally, click "Find Next"



4. The search may take a while, reminding us that the Windows Registry is a large and mysterious place where dragons be. Let's use these few seconds to reflect on the fact that you should never, ever, never change things in the registry unless you are absolutely, positively, totally, completely, 100%dead sure that you know exactly what you're doing. When the search completes we'll see the key name for which we're looking.



5. Click File->Export. Give your file an appropriate name like, "putty.reg" and click "Save"


6. We're done! Save the putty.reg file somewhere safe. The file doesn't contain any passwords or actual SSH key values so, it's relatively safe from prying eyes. Still, it does contain your configuration and that kind of data is a private matter.

Importing Your PuTTy Configuration

To import your saved PuTTy configuration on any other Windows computer simply copy your exported registry key, right click on the file and click "Merge"



Windows will ask you for confirmation that you want to import this set of registry values. We know this file is safe, because we created it but, you should never import registry information from an unknown source.


That's all you need to know about moving your PuTTy configuration from one machine to another. This can be really useful information when upgrading to a new PC or, if you're an office IT guy where your users all have a standard list of servers they need to connect via SSH, you can create a reference configuration on once machine and "share" it between every computer in the office. 


REFERENCES

Tuesday, May 29, 2012

Smartd Error: 1 Currently unreadable (pending) sectors

SkyHi @ Tuesday, May 29, 2012
 I am encountering following error in /var/log/messages:
Aug 15 03:55:42 hostname smartd[2366]: Device: /dev/sda, 1 Currently unreadable (pending) sectors
Which cause the / partition to be mounted as read-only. The server is accessible anyway but you cant do anything much inside. Lets troubleshoot this.

Collecting Information/Troubleshooting

I see read-only filesystem mounted when creating a test file in /root directory:
$ touch /root/testfile
touch: cannot touch `/root/testfile': Read-only file system
What is SMART daemon (smartd)?
Self-Monitoring, Analysis and Reporting Technology (SMART) system built into many ATA-3 and later ATA, IDE and SCSI-3 hard drives. The purpose of SMART is to monitor the reliability of the hard drive and predict drive failures, and to carry out different types of drive self-tests. We will use smartctl command to help us find out what is wrong with the disk.
Lets check the overall health of disk /dev/sda:
$ smartctl -H /dev/sda
smartctl version 5.38 [i686-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
 
 === START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
It passed. But it just general information only. We need to go deeper by do self-test to the disk:
$ smartctl -q errorsonly -H -l selftest -l error /dev/sda
ATA Error Count: 2
Error 2 occurred at disk power-on lifetime: 36795 hours (1533 days + 3 hours)
Error 1 occurred at disk power-on lifetime: 31542 hours (1314 days + 6 hours)
 
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       60%     39255         -
When I Google up the error above, it seems like the hard disk might have hardware problem. FSCK only might not helping much since it only fix logical error in file system, not the hardware error.
Errors reported by SMARTD is related to power-on lifetime attributes which explain as below (reference):
Count of hours in power-on state. The raw value of this attribute shows total count of hours (or minutes, or seconds, depending on manufacturer) in power-on state. A decrease of this attribute value to the critical level (threshold) indicates a decrease of the MTBF (Mean Time Between Failures).
However, in reality, even if the MTBF value falls to zero, it does not mean that the MTBF resource is completely exhausted and the drive will not function normally.

Backup

Since the hard disk is in read-only mode, we better do backup before proceed with any problem solving process. In this case, SCP to another server is good idea because we cannot write to the local disk at this moment. For me, “home” partition is the most important folder need to be saved:
$ scp -r /home user1@remoteserver:/home/user1/home_backup

Problem Solving Process

1. Remount the / partition:
$ mount -n -o remount /
mount: block device /dev/sda2 is write-protected, mounting read-only
2. Run e2fsck command to check ext3 file system online:
$ e2fsck /dev/sda2
e2fsck 1.39 (29-May-2006)
/: recovering journal
Clearing orphaned inode 31672817 (uid=0, gid=0, mode=0100755, size=157913)
Clearing orphaned inode 31672803 (uid=0, gid=0, mode=0100755, size=3532999)
Clearing orphaned inode 31666625 (uid=0, gid=0, mode=0100755, size=150604)
Clearing orphaned inode 31666619 (uid=0, gid=0, mode=0100755, size=383872)
Clearing orphaned inode 27885882 (uid=0, gid=0, mode=0100755, size=1011760)
Clearing orphaned inode 31666617 (uid=0, gid=0, mode=0100755, size=1141532)
Clearing orphaned inode 31665420 (uid=0, gid=0, mode=0100755, size=398180)
Clearing orphaned inode 31665416 (uid=0, gid=0, mode=0100755, size=71852)
Clearing orphaned inode 31671503 (uid=0, gid=0, mode=0100755, size=1250176)
/: clean, 80179/38273024 files, 2990728/38258797 blocks
Try remounting again the partition like step 1 but same error occurred. Proceed to next step.
3. Run full file system check using FSCK via rescue environment:
$ fsck -f -y /dev/sda2
Even the box remount correctly after that, the smartd status still haunting me up. This has force me to make final decision as my next step.
4. To avoid any sudden breakdown (since the disk already run more than 1000 days), I decided to replace the hard disk and re-install the box. Its better for me to do this as part of my maintenance task so I will not worrying much about ‘urgent’ maintenance when it breakdown during weekend or sleep time!

REFERENCES
http://blog.secaserver.com/2011/08/smartd-error-1-unreadable-pending-sectors/