New filesystem and harddrives?

I have been planning on upgrading my main PC which double as my HTPC fileserver at the end of the year when Intel releases Sandy Bridge.  A new motherboard, processor, a SSD, and some DDR3 were the original plan.  However, in light of my recent harddrive fiasco, my 250GB Seagates may be retired sooner then originally planned.  My SMART reallocated sector count (SMART id# 5) is at 7, and I anticipate it growing.  Until it becomes an issue I intend to keep using it, and send it out a few months before the warranty expires in 2011.

That said, I've been reconsidering my entire filesystem approach.  Originally I had the following setup:

• /dev/sd{a,b}1
• /boot partition consisting of /dev/sda1 and /dev/sdb1
• /dev/sda2
• Win7 system partition
• /dev/sdb2
• Linux root partition
• /dev/sda3
• Linux RAID0 striping + LVM

Following the harddrive failure, Win7 has been reinstalled on a partition on 1TB harddrive  (which is mostly my backup drive for Linux data), and my Linux root partition became the more stable /dev/sda2 partition since sdb is on it's way out.

That said, I've been looking for a way to pool my growing number of old disks in to a backup filesystem (I have a few old 120GB - 300GB PATA drives laying around).  I've looked at things like FlexRAID and unRAID, but they don't seem to be really that well thought out and more targeted for Windows HTPC users.  ZFS has been an industry buzzword for sometime, but it lacks native kernel level implementation in Linux, and I fear it won't let me add/remove drives on the fly (I don't want to use RAIDZ).

This leads me to btrfs or "butter fs".  So far I've gathered that it is seriously lacking in things like man pages, but for the most part it seems to work as a simple file system.  I've setup sda2 and sdb2 (my former Linux RAID0 + LVM) to be a btrfs.  My home directory (which is backed-up daily) has been running from it and so far it works as just a file system.  It has the filesystem metadata mirrored on both drives and the data is stripped.  I'm not sure of an effective way to benchmark the filesystem other then just use it, and so I will until my Seagate sdb drive is on its last legs leading me to RMA it and purchase some new Samsung Spinpoint 1TB F3 HD103SJs (which are the current hot ticket and pretty cheap @ $70 shipped from Newegg.  At that point, I'll pick something stable and go back to not worrying about it.

Until then btrfs has some other appealing features I'm looking to test out:

• Compression
• De-duplication
• Snapshots
• Multi-device file-system (ie the filesystem knows about two drives rather then letting RAID masquerade this.

First off, compression is just that, it seems that it uses zlib and compresses some files on the fly as it writes them resulting increased write/read speeds for plain-text compressible files.

I know I have multiple copies of the same file scattered all over my drive, and de-duplication is an easy way for me to save some space without doing anything.  Good deal.

Snapshots would be handy way to protect me from `rm -rf ./dir` followed my "OH SHIT".  Although my current nightly rsyncs to a backup drive make me feel plenty safe.

And finally, the most important is the multi-device file-system support.  This would enable me to replace md + LVM for my primary storage and it would help me to achieve my goal of pooling old disks for use as a backup.  I'm still having a hard time dropping my old way of RAID thinking where all the drive properties have to match.

So, for example, say I have a ghetto RAID setup (which I do for the purposes of testing), like:

• /dev/sda3 (190GB)
• /dev/sdb3 (190GB) and is maybe dying
• /dev/tb1/btrfstest (70GB) lvm on a 1TB WD Black

You could start out by striping data and mirroring metadata like this:

# mkfs.btrfs -L newhome /dev/sda3 /dev/sdb3

# mount /dev/sda3 /home

 You then copy your home data over using rsync...
Now, at this point I wanted to remove /dev/sdb3 from the setup, but was shot down with: 

# btrfs-vol -r /dev/sdb3 /home
btrfs: unable to go below two devices on raid1

Okay, so lets add that logical volume from my 1TB drive just for kicks and then re-stripe/balance the data for performance.

# btrfs-vol -a /dev/tb1/btrfstest /home
ioctl returns 0
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             461G   56G  402G  13% /home
# btrfs-vol -b /home

That easy huh?  All without unmounting the filesystem (and infact, all while writing this).  Now lets pretend sdb3 starts dying again and we want it out as we tried before:

# btrfs-vol -r /dev/sdb3 /home

Filesystem grinds and after some time it finishes.  Running dmesg shows it's working:

btrfs: found 2594 extents
btrfs: found 2594 extents
btrfs: relocating block group 84854964224 flags 9

Easy enough, and impressive to say the least. The only real question now is, if I can add/delete drives to btrfs filesystems on the fly, should I go for data striping and possibly (not confirmed with btrfs method of striping objects) incurring a latency penalty, or just have the data in "single" for the backup volume(s).

Time will tell...

Cut the Cable

I'm moving soon, and I've pledged to cut the cable.  I'm currently with AT&T U-Verse and have 6/1Mb/s Internet and their U200 package with HD.  I realize I never watch anything except the HD channels, and even then 75% of it is stuff I can get over the air (OTA) from the major networks.

This is where my little project to build a Home Theater PC (HTPC) started.  I could build a computer for cheap (less then $500) that would pay for itself after I killed by cable bill.  The HTPC would hook up to my HDTV and let me watch what OTA signals and record them using Windows 7 Media Center as well as access Hulu, YouTube, my existing movie and music collection.

Add in netflix and I should be pretty good...

The missing networks are CNBC, Discovery, National Geographic, History, Speed, and ESPN.

Duplicity + GPG Compression

Duplicity home directory with mostly binary files (pdf, images, etc) with default compression:

$ duplicity --encrypt-key=96907DB4 --sign-key=96907DB4 --include=/home/nitro/svn --exclude=/** --volsize=250 / file:///mnt/backup/duplicity/default

--------------[ Backup Statistics ]--------------
StartTime 1276259659.02 (Fri Jun 11 07:34:19 2010)
EndTime 1276259918.87 (Fri Jun 11 07:38:38 2010)
ElapsedTime 259.85 (4 minutes 19.85 seconds)
SourceFiles 34343
SourceFileSize 1758582413 (1.64 GB)
NewFiles 34343
NewFileSize 1758582413 (1.64 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 34343
RawDeltaSize 1700087247 (1.58 GB)
TotalDestinationSizeChange 1134113085 (1.06 GB)
Errors 4
-------------------------------------------------

Duplicity home directory with mostly binary files (pdf, images, etc) with bzip2:

$ duplicity --encrypt-key=96907DB4 --sign-key=96907DB4 --include=/home/nitro/svn --exclude=/** --volsize=250 --gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9'  / file:///mnt/backup/duplicity/bz2

--------------[ Backup Statistics ]--------------
StartTime 1276258959.45 (Fri Jun 11 07:22:39 2010)
EndTime 1276259564.09 (Fri Jun 11 07:32:44 2010)
ElapsedTime 604.64 (10 minutes 4.64 seconds)
SourceFiles 34343
SourceFileSize 1758582413 (1.64 GB)
NewFiles 34343
NewFileSize 1758582413 (1.64 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 34343
RawDeltaSize 1700087247 (1.58 GB)
TotalDestinationSizeChange 1082959785 (1.01 GB)
Errors 4
-------------------------------------------------

 Duplicity backup of /etc with mostly plain-text files with default compression:

$ duplicity --encrypt-key=96907DB4 --sign-key=96907DB4 --include=/etc --exclude=/** --volsize=250 / file:///mnt/backup/duplicity/default

--------------[ Backup Statistics ]--------------
StartTime 1276260094.21 (Fri Jun 11 07:41:34 2010)
EndTime 1276260099.76 (Fri Jun 11 07:41:39 2010)
ElapsedTime 5.55 (5.55 seconds)
SourceFiles 1393
SourceFileSize 6574960 (6.27 MB)
NewFiles 1392
NewFileSize 6570864 (6.27 MB)
DeletedFiles 2
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 1394
RawDeltaSize 5887730 (5.61 MB)
TotalDestinationSizeChange 968617 (946 KB)
Errors 31
-------------------------------------------------

Duplicity backup of /etc with mostly plain-text files with bzip2 compression:

$ duplicity --encrypt-key=96907DB4 --sign-key=96907DB4 --include=/etc --exclude=/** --volsize=250 --gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9'  / file:///mnt/backup/duplicity/bz2

--------------[ Backup Statistics ]--------------
StartTime 1276260124.50 (Fri Jun 11 07:42:04 2010)
EndTime 1276260127.12 (Fri Jun 11 07:42:07 2010)
ElapsedTime 2.62 (2.62 seconds)
SourceFiles 1393
SourceFileSize 6574960 (6.27 MB)
NewFiles 1393
NewFileSize 6574960 (6.27 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 1393
RawDeltaSize 5887730 (5.61 MB)
TotalDestinationSizeChange 845953 (826 KB)
Errors 31
-------------------------------------------------

In conclusion, it seems that the default options are sufficient in most cases for my backups and the time trade-off isn't worth using bzip2.

Seagate FAIL

I run two ST3250620AS as my root file system with a Linux software RAID0 setup for my /home directory. These drives are from Seagates 7200.10 series which were the first drives to switch to perpendicular recording some years ago.  This was a time Seagate had a 5 year warranty for OEM drives and am immaculate reputation.

Starting on Friday, I heard my harddrive clicking.  Some quick investigation by looking at logs revealed that sdb was dying to some degree:

Jun 11 14:21:38 core kernel: ata3.00: exception Emask 0x10 SAct 0x1 SErr 0x810000 action 0xe frozen
Jun 11 14:21:38 core kernel: ata3.00: irq_stat 0x08400000, interface fatal error, PHY RDY changed
Jun 11 14:21:38 core kernel: ata3: SError: { PHYRdyChg LinkSeq }
Jun 11 14:21:38 core kernel: ata3.00: failed command: READ FPDMA QUEUED
Jun 11 14:21:38 core kernel: ata3.00: cmd 60/60:00:7d:8d:25/00:00:10:00:00/40 tag 0 ncq 49152 in
Jun 11 14:21:38 core kernel: res 40/00:00:7d:8d:25/00:00:10:00:00/40 Emask 0x10 (ATA bus error)
Jun 11 14:21:38 core kernel: ata3.00: status: { DRDY }
Jun 11 14:21:38 core kernel: ata3: hard resetting link
Jun 11 14:21:41 core kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Jun 11 14:21:41 core kernel: ata3.00: configured for UDMA/133
Jun 11 14:21:41 core kernel: ata3: EH complete

I noticed the clicking when I took the side of my case off to look at something else, and figured maybe I bumped the cable.  I touched the cable and it seemed happy.  I wrote it off as a bad cable and replaced the cable later that day when I had a chance to power down the machine.  I noticed that one of the contacts was recessed a bit more then the others, so I swapped it and looked at the others.  Two others were bad, so I just threw them out and visually inspected the replacements.

Fast forward a few hours and it's acting up again.  This time I dig deeper with smartctl and run some tests, the first drive in the array passes without problems, but the other has some serious issues.  I downloaded Seagate's Seatools CD and booted off of that since my attempts at running the S.M.A.R.T. long test from Linux failed.  Running it from the CD found 2 bad sectors (on top of 7 that were already remapped) and give me the option to repair them, and so far so good.  See my smartctl data below.  Also note this drive is almost 4 years old but reports a lifetime of only 4718... I think that's an oops on Seagate's part as this drive has been on 24/7 since then.

$ sudo smartctl -a /dev/sdb
Password:
smartctl version 5.38 [x86_64-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.10 family
Device Model:     ST3250620AS
Serial Number:    5QE0DYWW
Firmware Version: 3.AAC
User Capacity:    250,059,350,016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Jun 13 10:00:31 2010 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)    Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)    The previous self-test routine completed
                    without error or no self-test has ever
                    been run.
Total time to complete Offline
data collection:          ( 430) seconds.
Offline data collection
capabilities:              (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003)    Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01)    Error logging supported.
                    General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   1) minutes.
Extended self-test routine
recommended polling time:      (  92) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   111   086   006    Pre-fail  Always       -       34962761
  3 Spin_Up_Time            0x0003   092   089   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       323
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       7
  7 Seek_Error_Rate         0x000f   085   060   030    Pre-fail  Always       -       341869071
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       4720
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   020    Old_age   Always       -       1031
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       119
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   056   050   045    Old_age   Always       -       44 (Lifetime Min/Max 41/44)
194 Temperature_Celsius     0x0022   044   050   000    Old_age   Always       -       44 (0 14 0 0)
195 Hardware_ECC_Recovered  0x001a   077   053   000    Old_age   Always       -       14538
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 TA_Increase_Count       0x0032   100   253   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 119 (device log contains only the most recent five errors)
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 119 occurred at disk power-on lifetime: 4715 hours (196 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 01 55 1a 5e e0  Error: UNC at LBA = 0x005e1a55 = 6167125

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 00 78 13 5e e0 00      01:06:52.649  READ VERIFY SECTOR(S) EXT
  42 00 00 78 0b 5e e0 00      01:06:52.631  READ VERIFY SECTOR(S) EXT
  42 00 00 78 03 5e e0 00      01:06:52.618  READ VERIFY SECTOR(S) EXT
  42 00 00 78 fb 5d e0 00      01:06:52.600  READ VERIFY SECTOR(S) EXT
  42 00 00 78 f3 5d e0 00      01:06:52.587  READ VERIFY SECTOR(S) EXT

Error 118 occurred at disk power-on lifetime: 4715 hours (196 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 01 77 bb 1b e0  Error: UNC at LBA = 0x001bbb77 = 1817463

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 00 00 b8 1b e0 00      00:57:43.347  READ VERIFY SECTOR(S) EXT
  42 00 00 00 b0 1b e0 00      00:57:43.334  READ VERIFY SECTOR(S) EXT
  42 00 00 00 a8 1b e0 00      00:57:43.317  READ VERIFY SECTOR(S) EXT
  42 00 00 00 a0 1b e0 00      00:57:43.304  READ VERIFY SECTOR(S) EXT
  42 00 00 00 98 1b e0 00      00:57:43.287  READ VERIFY SECTOR(S) EXT

Error 117 occurred at disk power-on lifetime: 4711 hours (196 days + 7 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 55 1a 5e ee  Error: UNC at LBA = 0x0e5e1a55 = 241048149

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 50 1a 5e ee 00      05:47:25.395  READ DMA
  27 00 00 00 00 00 e0 00      05:47:23.485  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      05:47:23.427  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      05:47:23.426  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      05:47:23.426  READ NATIVE MAX ADDRESS EXT

Error 116 occurred at disk power-on lifetime: 4711 hours (196 days + 7 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 55 1a 5e ee  Error: UNC at LBA = 0x0e5e1a55 = 241048149

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 50 1a 5e ee 00      05:47:19.397  READ DMA
  27 00 00 00 00 00 e0 00      05:47:23.485  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      05:47:23.427  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      05:47:23.426  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      05:47:23.426  READ NATIVE MAX ADDRESS EXT

Error 115 occurred at disk power-on lifetime: 4711 hours (196 days + 7 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 55 1a 5e ee  Error: UNC at LBA = 0x0e5e1a55 = 241048149

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 50 1a 5e ee 00      05:47:19.397  READ DMA
  27 00 00 00 00 00 e0 00      05:47:19.396  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      05:47:19.338  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      05:47:19.338  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      05:47:17.436  READ NATIVE MAX ADDRESS EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      4718         -
# 2  Short offline       Completed without error       00%      4716         -
# 3  Short offline       Completed: read failure       90%      4716         241048149
# 4  Short offline       Completed: read failure       90%      4714         241048149
# 5  Short offline       Completed: read failure       90%      4712         241048149
# 6  Short offline       Completed: read failure       90%      4712         241048149
# 7  Short offline       Completed: read failure       90%      4710         169589623
# 8  Extended offline    Completed: read failure       90%      4706         169589623
# 9  Extended offline    Completed without error       00%      4400         -
#10  Short offline       Completed without error       00%      4397         -

How to disown stuff because of UTF-8

I've been uploading files to DreamHost for a two days now, and duplicity just purrs away in my gnome-terminal shell doing what it does, out of sight and out of mind. However, one day I reallllly wanted to fix the annoying encoding default of ANSIX3.4-1968 gnome-terminal on my Gentoo machine.

After some research I learned that I needed to tweak some environmental variables and restart my gnome-terminals as they all run as one process it seems. I could test this out by setting LANG=en_US.UTF-8 and running `gnome-terminal --disable-factory` causing it to start a new process. Perfect, now I can fix everything. I dug through my init scripts and found that on Gentoo gdm (aka xdm in someplaces) sets the LANG variable that gets inherited down stream. I made an /etc/env.d/02locale file with the following:

LANG=en_US.UTF-8
GDM_LANG=en_US.UTF-8

I ran env-update and all I needed to do was reload gdm and log back in.

Not quite that easy as I still have this duplicity process running and was approaching halfway at 2 days. If I had been smart when I started the backup I would have ran it in screen and just detached the screen session and let it run in the backgound, but I wasn't.

There had to be a way to change the parent of the process I thought, and after some googling I discovered the bash disown function. Awesome. Apparently I could change the parent of the running processor so it wouldn't close when I closed the terminal and subsequently my X session. So I opened the gnome-terminal running duplicity, CTRL+Z to stop the process, then I ran `bg` to background it in that terminal, and then I ran disown, and bam, its parent had changed to the init process as viewed by `pstree` success. Restarted my X session and it was still happily uploading away.

Now I know how to disown my computer and am no longer frustrated by UTF-8 and gnome-terminal.

Retire My Old Colocated Server

The time has come to save a few bucks on something I don't use anymore -- my colocated web/mail/dns server. In November of 2005 I put together the parts to a modest Pentium 4 webserver with a long time friend. We took it to a colocation place in Troy, MI called waveform.net that offered space for a Tower Server, 100Mb/s Internet connection and 1TB/mo of transfer.... for $50. Ridiculous deal.

We did that, ran fine for years (actually the server never had any problems short of the BIOS on the ASUS motherboard was uber slow booting some timers). Hosted tons of crap and experiments on there. One day it dropped offline, called and called and called the host. Never an answer, no email, no phone call back. So, I decided to drive there and pick itup and move it to colostore.com which was 4 hours closer to home for the same services + KVM on request. Excellent decision and I've enjoyed colostore.com for 2 years now. However, the server no longer does much for me and it's time to move on.

If anyone is looking for a solid reliable colocation company for their personal server, I recommend colostore.com. They have raised their prices since I started, but still worth it. The building isn't quite what you'd expect a "datacenter" to look like, but it got the job done for me and did it better then the guys before them.

I always figured I'd move to a small $20/mo virtual private server running on XEN virtualization technology. However, I always felt restricted by available diskspace and memory. Then the other day I saw a deal on slickdeals.net for DreamHost. Came out to something liek $66/2 years of webhosting with "unlimited" diskspace, transfer, domains and mail accounts with ssh access. Cool, I can move all my domains and be happy, main priority was email and that the server has SMTP + TLS/SSL and IMAP over SSL. They do.

Researched the name and you get bad stuff here and there, but otherwise gather that they are a huge company and fairly well known, so with that comes bad press. The price combined with the recommendation from lifehacker.com a few weeks ago and I was sold. For $60+ for 2 years, if I don't like them then I move in 2 months and call it a savings over the colocation deal I'm leaving.

Here I am, with a DreamHost account and so far so good in my opinion. I've moved half a dozen sites and still have 2 more to go. Most notably I've moved a 50GB subversion repository for a student organization I was a part of when I was in school... all without a hitch. Their server ( yangon.dreamhost.com ) that hosts my site has a very low load averages and transferring the files form the ColoStore in Indiana to DreamHost in California all zipped along over rsync+ssh at 9MB/s +. Pretty solid if you ask me. I'll post some specs about the server later. I figure in a few months we will see how much they actually oversell their servers.

DreamHost and Duplicity Backups

I started on Monday backing up my home computers to DreamHost backup using duplicity.

DreamHost gives their shared hosting users 50GB of backup for personal files. DreamHost offers "unlimited" diskspace on their webservers for hosting files accessed by the web. However, my personal files aren't to be accessed by anyone but me and I just wanted an offsite backup.

I researched backup solutions, initially turning to my tried and true over the past 10+ years rsync scripts. However, I don't trust DreamHost to keep my data secure, so I *need* encryption. I narrowed down the choices to either a TrueCrypt image that I could mount in Linux and then split and rsync, or use duplicity.

I considered TrueCrypt for quite a while as the community following for it is rather impressive. However, syncing a single large image wasn't feasible. Splitting the 30-50GB image in to smaller pieces (guessing 250MB maybe) using the UNIX split command seemed to work with rsync, only transferring the major parts seemed to work on a 1GB test file I modified parts of. However, this just meant that now I needed to always keep 50GBs of space free so I could split the image which in turn was sync'd upstream.

I then resorted to duplicity. Initially, I didn't like idea of using tar (behind the scenes) which was then encrypted using GPG. I'm a long time users of rsync, where if I need one or two files I can instantly access them. However, I can't remember the last time I needed to that, so I bit the bullet and tried it. GPG is more secure as well (in my opinion) then TrueCrypt.

On Monday I gave it a shot, backing up my system's /etc directory and /home for the time being. The --dry-run in duplicity calculated approx 31GB of data to be copied... do some math using Wolfram Alpha considering my ~ 700Kb/s upload and we get 4 days 2 hours. Lovely, okay so my system will be hogging my Internet for a few days.

Some more research (via Google not firsthand) seems to suggest that duplicity won't pick-up where it left off either should it get interrupted, one of the features rsync does very well since it only deals with items on a file by file basis. So, I'll let it run.

After that I'll do incremental backups and then do a full backup next month. I also need to research compression algorithms in gpg's by adding "--gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9'" to duplicity's options.

Oh yeah, and I need to make sure I can restore the backup.