Archive

Archive for June, 2009

Backup Strategies

June 20th, 2009 11 comments

With my primary hard drive (a three-year old WD Raptor WD740) having been on life support, so to speak, for the last 3 months, I’ve been a lot more diligent about keeping backup copies of my data. Every couple of days, I log out entirely and run a simple rsync script to copy my entire /home directory to a specialized partition on my secondary disk, which I keep at /mnt/backup for simplicity sake.

While its parameter handling can be a bit quirky, I find that it is extremely useful for two reasons: The first more or less negates its quirky parameter handling: Clear and thorough documentation, with lots of example program calls  The second is that it saves me a lot of time in copying the files. Similar to the DeltaRPM feature I raved about with Fedora 11, it copies over only the changed content instead of the entire directory tree. With my home directory at nearly 20 GB, incrementally updating my backup like this prevents a good 90+% of the data from needing to be copied again.

In this way, I know that I have at least two copies of my data at any given time. A major plus to copying the directory tree as-is is that, once the drive does die and I replace it, I merely need to copy it over, without changing anything or unpacking huge tarballs and applying diffs, et al.

The disadvantage to this is that I only have one consistent backup copy of my data at a given time, and that backup is on a hard drive in the same computer. So, should there be a massive system failure of some sort (knock on wood!), then I would lose my data for certain. I also intend to purchase CD-RWs for this purpose – that is, as an additional backup medium – in the near future. But for right now, the second on-disk copy suffices. I also want to setup a RAID system in my next computer build…but that’ll have to wait. 🙂

So this simple rsync method, as with any storage decision, has its benefits and downfalls:
Pros:

  • Easy to configure;
  • Can be automatically run (e.g., in a cron job);
  • Updates occur via content deltas, not full copies;
  • Backup data is “as-is”, and can be used immediately after copying.

Cons:

  • Only one backup copy;
  • Physical proximity to original data;
  • Requires space for an entire duplicate of the directory tree.

For me, though, this method works out well. Do others have a similar system? Would you suggest any improvements/simplifications? I’d like to hear your thoughts on the matter! Thanks.

Leonidas: On the Brink of Release

June 9th, 2009 2 comments

With Fedora 11 (“Leonidas”) released earlier today and Rawhide looking to the future, I find myself instead looking back at what has made Leonidas such an excellent release.

With over 50 new features in this release (more than any previous release, I’ve been told!), it would seem logical that this staggering amount of new improvements would leave us with many majors bugs and issues yet to resolved – the more features we add, the less manpower/resources we can expend on each individually, right?

Wrong. With so many test days and an amazing Quality Assurance team, we’ve hammered, smashed, pounded, banged, and kicked this release into a uniquely rich and stable Fedora experience.

One of my favorite features of this release is Presto. Though not enabled by default, Presto allows users to use so-called DeltaRPMs to update the packages installed on their system. That is, instead of downloading the whole new updated packages, only the changes between the installed version and the update need be downloaded. Especially for large packages (such as some game data and OpenOffice.org) or those who are on a slower or pay-per-usage internet connection, this can be a very hefty savings both in time and cost. I used it immediately after installed Leonidas, and it saved me quite a bit on the initial updating:

Size of all updates downloaded from Presto-enabled repositories: 14M
Size of updates that would have been downloaded if Presto wasn't enabled: 128M
This is a savings of 89 percent

Win! The DRI2/KMS support has also been updated heavily and now works out of the proverbial box, at least for a large portion of Intel and AMD/ATi hardware. (This allows a proper composited desktop with 3-D and all. By default. VERY awesome.)

Another excellent feature is that the installation now defaults to using the Ext4 filesystem where applicable. I must admit, I was a bit afraid of actively using this when I was first reading about it, due to all of the reports of data corruption people have experienced; but it seems those issues are long-since fixed, as I’d been using Ext4 for my root partition since Fedora 10. With Leonidas, I took the plunge and upgraded my /home partition (via Anaconda) from Ext3 to Ext4, and have yet to notice a problem. (For those wishing to do similar – and even for those not – I would still highly recommend keeping proper backups Just In CaseTM)

Finally, while I could pinpoint each and every feature and how I feel it’s improved Fedora, suffice it to say that I don’t have adequate time to type out such a long rave. However, as much as these individual features improve Fedora on their own, it is their conglomeration which impacts us the most – the way things are so well-integrated and work properly “out of the box” (so to speak), the way that we as a community of many actively support all of this so well, the way we as a community so diverse handle bugs and packaging, the beautiful artwork and the amazing work of the Release Engineering team to distribute this blend of creativity so readily.

I’d like to rehash those last few points: It’s the wonderful combination of the efforts of you countless contributors and users which makes Fedora so great. Thank you all. Keep up the impressive work. I can’t wait for what’s to come in Fedora 12+!