This morning, I received the Open-RD I bought a few days ago and started playing with my new device. One of the first thing I wanted to access was (of course) the system console. While the default setup provides a SSH daemon and even GDM and a full desktop, my goal is to have FreeBSD on this device and move the services I run at home from my personal computer to this low-consumption computer (and I don't intend to switch to GNU/Linux).
Since the console is usually available on the serial port, I looked for some cable to connect the OpenRD to my computer. Unfortunately, I didn't have the required cable. I then spent about two hour with various serial cables, cables looking like serial cables but which where not serial cables, parallel SUB-D25 connectors, a serial SUB-D25 cross-over cable and a soldering iron to build a null-modem SUB-D9 serial cable. Unfortunately, when I connected my computer to the OpenRD, I was still not able to access the console using cu(1).
After reading a bit of documentation, I realised I missed the fact that the console was available on USB and not via the serial port. However, FreeBSD did not recognised the chip the OpenRD uses to provide serial over USB support.
Using usbconfig(8), I could get the vendor ID and product ID the uftdi(4) driver was lacking. I patches the source code and a few minutes later could enjoy a set of new devices when I plug the OpenRD on my computer:
% ls /dev/cuaU* /dev/cuaU0 /dev/cuaU0.init /dev/cuaU0.lock /dev/cuaU1 /dev/cuaU1.init /dev/cuaU1.lock
I can now access the OpenRD console using cu(1):
% cu -l /dev/cuaU1 -s 115200
\o/ I can boot a FreeBSD 8.0-STABLE arm kernel!
I filled-in the usb/140951 problem report in the FreeBSD GNATS with the patch. If you own an OpenRD and want to have access to the console, the patch is just waiting for you.
…but setting up a valid and working backup infrastructure is usually a PITA. So, after having read some positive reviews about Tarsnap, I’m going to set it up for my personal files.
After the final preparations have been wrapped up, FreeBSD 8.0 is a fact and ready for download or upgrade. The all the new features and improvements are too numerous to mention, ranging from networking, scalability, virtualization, wireless, ZFS to USB. See the official announcement, or even better, a comprehensive article by Remko Lodder, for more information.
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
Welcome to FreeBSD 8!
In this article I will write about the latest release from FreeBSD, 8.0. This is a major version that offers new functionality and much improved parts of the code.
Why are major releases so special?
Major releases offer the possibility to include changes in the system that are not allowed in stable branches. This could be new applications or API/ABI interfaces, or serious changes to datastructures and things like that.
FreeBSD brings out major releases every 18 months. Ofcourse the 18 months may vary, depending on the amount of new features and problems found while preparing for the first .0 release. The schedule should guide as a reference on when to expect something new.
FreeBSD 8?
FreeBSD 8 will be the latest version of FreeBSD that is currently on the market, it was preceded by FreeBSD 6 and 7, where we found features like ZFS, Improved Jail support, the widely known Danish Axe was used to further take out the GIANT lock, and many more features that had been in the previous release.
What will FreeBSD 8 offer us?
FreeBSD 8 will offer us the following:
USB Storage hotplug removal
Previously it was not possible to take out lets say an USB storage device while the operating system was running, without crashing it. The system code is updated to make it possible to take out an USB storage device without the system crashing. This will make many people happy!
Multi-IP/IPv6 jails
With FreeBSD 8 it will be possible to assign multiple IPv4 addresses to a jail, as well as assigning IPv6 addresses. People that offer hosting services can greatly enjoy these features, a jailed webserver for example can now use many more addresses and do proper SSL virtualhosting.
NFSv4 support
NFSv4 support is added to the FreeBSD Operating System, while this is still experimental, it gives you a NFSv4 client, as well as a server that can service NFSv4 nodes. NFSv4 gives you better security access control’s, a stateful protocol, performance improvements, etc.
Enhanced ULE scheduler
The ULE scheduler is much improved for FreeBSD 8, this allows even better scheduling and responses to systems running FreeBSD 8, especially when used with SMP systems. Systems running the FreeBSD 8 operating system, have this scheduler enabled by default.
DTrace
DTrace is a suite of applications imported from Solaris. DTrace will assist you in profiling your system and applications, data which you can use to make the system perform even better under your specific configuration. Every key developer needs a tool like this.
Wireless Mesh Networking
The Wireless Mesh Networking (802.11s) is an experimental feature and early adoption framework that gives the ability to setup a Meshed Wireless network. Currently most Wireless networks are build around one central access points, with leaf nodes / bridges / repeaters attached to them. This experimental feature offers the ability to ‘perfectly’ roam accross the network, without being tied to one specific Access Point.
VIMAGE
VIMAGE, is an network virtualisation project that aims in delivering multiple networking related instances. So for example you can give your jails, their own vimage, enabling them to run IPSEC, Packet filter(s), setting their own routing tables etc. So this actually makes your jails, more or less independant servers.
Multiple routing tables
Multiple routing tables, enable you to select different routing tables for different services. For example you can setup different routes for your webserver(s) and mailserver(s). The “setfib” utility is added to provide a management layer for these FIB’s (Routing tables).
Equal Cost multipath routing
Equal-Cost Multi-Path Routing (ECMP) is a new feature under FreeBSD 8, that enables the administrator to loadbalance traffic by equally balancing traffic over various routes. In theory this could increase the bandwidth that you can use, so be sure to check this out!
FreeBSD ports Parallel building
The FreeBSD ports framework is adopted to that multiple ports can be build at once. People with multi core systems will definitly see significant improvements in this region. While this update is not limited to the 8.0 release itself, it is the first release that will have this feature onboard. (after fetching the ports tree ofcourse).
MPSafe TTY
The TTY subsystem is one of the last sections of the entire operating system that had not been rewritten or massively updated in the last decade or two. FreeBSD 8 will have a replaced version that no longer uses the GIANT lock. That reduces the impact of the lock even more and will assist with fine grained multiprocessor capabilities. It is also more modular and will make it easier to hook into the new layer. This will help in lagging console and X.org sessions.
Procstat
Procstat is a new application, eliminating the need for procfs(4), it gives the user information about processes, command line arguments, kernel thread stacks, and many other functions that could assist people in troubleshooting and debugging.
Textdumps
Textdumps had been written to make it much easier to get coredump information back from the Operating System after fatal events occured.
The application had been setup to generate a tar archive that includes several text files with valuable troubleshooting information. Users that send this tar file to one of the appropriate lists, make a much better chance in getting their problem fixed. Before this tool one needed to do this manually, often making this an impossible step for the average user. Not only will this help the user that is facing problems, but also the bugbusters that will have all required information available without needing to explain on how to get the information there.
Experimental AHCI driver
An experimental AHCI driver had been added to the tree, which gives direct and native AHCI commands through the CAM layer. This includes the NCQ feature (Native Command Queueing).
Gvinum v2
Gvinum had been updated and reworked, making it much more production ready and usable then before.
Disk utility upgrades
Several disk utility applications had been updated, or adjusted to become the default. For example the GEOM_PART utility becomes the defacto standard for disk slicing. One should pay attention when this comes in to play though, since the labels might be read differently with GEOM_PART your devices might be enumerated in a different way then before. Make sure you are actively involved with the upgrade and make sure you have serial access to the machine in case of problems!
Beyond that GPT partitions are now capable of being boot from, and the bsdlabel utility supports up to 26 partitions now.
ProPolice Stack Protector
The ProPolice SSP framework is added to the builds, protecting the kernel and userland (where configured) from being stack-smashed. This will make it harder to exploit stack based buffer overflows.
ZFS
ZFS is updated to version 13, and sees several improvements. The experimental warning is removed, making it a production ready filesystem which you can use with very large datapools. Make sure you have enough memory when playing with it though!
Wireless Virtual AP
The Wireless code is updated to support Virtual AP’s. Within the /etc/rc.conf file you are now able to clone the ‘direct hardware interface’ like ath0 into a wlan device. If you clone this more often you will be able to support more SSID’s and things like that. For small companies or freaky home users, you can setup your own protected SSID, and a guest SID which visitors can use and is protected differently.
VirtualBox Host support
The FreeBSD ports tree saw VirtualBox added to the tree, making FreeBSD 8 one of the possible candidates for Virtual Machines delivered through VirtualBox. This makes it a good alternative for VMWare.
NULL-pointer dereferences made harder
The FreeBSD Security Team included a little rewrite of the NULL pointer handling within FreeBSD. Programs are no longer able to make use of the NULL pointer by default and will be stacked on a random address location. This feature makes FreeBSD a bit safer against NULL pointer dereference vulnerabilities.
lukemftpd build disabled by default
Personally I axed the build of lukemftpd. This is one of the two ftp daemons that we have in the base system, and was opted for removal a long time ago. That had happened and the daemon is no longer available by default on the latest version of FreeBSD. Further removal of the lukemftpd software will be investigated to see what consequences will popup because of that.
How to upgrade?
Now that we spoiled you with all the new features in FreeBSD 8, there is probably interest in how one can upgrade to the FreeBSD 8 release.
Before explaining the process of upgrading the system, I expect that you already have a FreeBSD system running on 7.2 or 7-STABLE, if you are unsure on how to get that going, please refer to my previous article in BSDMag which explains this in great detail (and it includes pictures too!).
Ofcourse it is also be possible to install FreeBSD 8 from CD/DVD, please browse to ftp://ftp.langcode.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-yourarchitecturehere/8.0
and fetch the proper media. All you have to do is follow the instructions that are printed on screen. If you need more details about this, there is an excellent handbook that will guide you through it, or again my previous article will assist you. The FreeBSD handbook can be found here:
http://www.FreeBSD.org/doc/en/books/handbook/
In some cases there are localised versions, like the Dutch Handbook:
http://www.FreeBSD.org/doc/nl/books/handbook
replace ‘/nl’ by ‘/yourlangcode’ to see whether your version also exists.
As mentioned we will be upgrading a running 7.2 / 7-STABLE system to FreeBSD 8.0-RELEASE.
We use “csup” for this, which will fetch our source code. This will lead up to a new system and new kernel.
For the instructions that follow, you will need “root” access, if you do not have this access, please consult your system administrator and ask him for help on how to upgrade FreeBSD as “root”.
Copy over the example csup file to /root and begin editing:
# cp /usr/share/examples/cvsup/stable-supfile /root/8-release
# vi /root/8-release
Navigate to the line which mentions ‘default host’, and change it to a server near you, so for example in the Netherlands you would use:
*default host=cvsup.nl.FreeBSD.org
Now find the part that has ‘default release’ mentioned. We need to update that as well. Change the contents of the tag parameter to RELENG_8_0. Thus the line would look like something as:
*default release=cvs tag=RELENG_8_0
Note that there is another tag that will give you the actual release bits (RELENG_8_0_0_RELEASE), but this will not get updated for Errata Notice’s and Security Advisories, making it an unwanted tag to use.
After making sure the above updates were done, we will need to update our tree. If you are a survivor of my previous article you will have an old tree and old objects tree which you might want to save for future reference.
# mv /usr/src /usr/src.releng7
# mv /usr/obj /usr/obj.releng7
Now we can download / update the new tree.
# csup /root/8-release
Wait for it to finish, and after that we can build a new kernel and world. We will not do modifications to the kernel and world this will be very straightforward.
# cd /usr/src
# make buildworld && make buildkernel
This will generate both a new world, and a new kernel, which we will use later on.
When this had been done, we will update the configuration files by issueing:
# mergemaster -p
This will update the configuration files that are needed before the new release can be started at all. If no output is given then the current configuration is sufficient to start the 8.0 version later on.
Configuration had been updated, so we can start by installing the kernel, after which we need to reboot the system:
# make installkernel
# reboot
The system will restart, when the bootloader starts, press a key and/or start the system in single user mode. In case you do not have the menu; you should issue “boot -s” on the command line so that the system starts in single user mode.
Assuming that nothing went wrong and the system starts normally into the single user mode, we can continue by installing the new world.
# cd /usr/src
# make installworld
Next we need to run a new mergemaster, but this time without any additional flags, so that “optional” configuration files will get updated.
# mergemaster
Walk through all differences and make updates where you think they are appropriate. Be carefull though, if you update passwd and group, you might no longer be able to login remotely. I have been there, done it and got the t-shirt. Again I’d assume you made all the changes you wanted to, without messing up with the system itself. We need to reboot one more time before we can be a happy 8.0 user.
# reboot
And the system will reboot and restart all services under the new world order.
Updating the jails:
In my previous article we also installed jails, that will do our hosting needs, without compromising the host machine. They are not updated through the way described above. Though a fairly simple way of doing that is by installing the new world over the old jail-world. For this you need to stop the jails, because otherwise the system might not be able to update essential files because they are in use.
Once again navigate to the usr/src tree so that we can start by updating the jails. I’d assume you have stopped the jails already so we are safe to go.
# cd /usr/src
Next, update the jails master infrastructure:
# make installworld DESTDIR=/home/j/mroot
However, please do note that it might be possible that certain ports need to be rebuild. Carefully inventorize what kind of applications you currently use, and check whether they might be using libraries that are no longer provided. After you did this you are free to cleanup old libraries:
# cd /usr/src
# make delete-old-libs
# make delete-old
Again this is at your own risk. If you fail to update bash for example to use the new libraries, you are no longer able to restart it if you relogin. Again I have been there, done it and, got a nice second t-shirt!
Conclusion:
So now you are running a fresh and modern 8 system, which you can use to do various kind of (new) things. Not only did we update your base system, we also updated your jail infrastructure and you also updated several ports so survive this cleanup. You also got an impression about what new features you can use under FreeBSD, so I’d suggest you start playing with them now. In case you find problematic things, please consider sending an email to the various mailing lists of FreeBSD, located at http://lists.FreeBSD.org
In case of a more serious problem, which cannot be resolved by the various mailing lists, please consider sending in a bug report so that the developer crew can act accordingly and if there is enough information available resolve the problem you are facing.
Do realise though: Most people working on FreeBSD is a volunteer, who all work for bosses or are being hired for different projects. They also have families, kids, and a social life that demand attention. Please take care when sending in a problem report. Make the report as detailed as possible, send in the textdump if that is available, and give people time to respond. Most often a gentle prod works better then bashing around.
References:
I used Ivan Voras’ list of “Whats cooking for FreeBSD 8″ as my main source for new and improved updates. You can find the list at the following URL:
http://ivoras.sharanet.org/freebsd/freebsd8.html
About the Author:
Remko Lodder is a 26 year old FreeBSD enthusiast, in his spare time he likes being with his son and girlfriend, playing with FreeBSD systems, and wearing various FreeBSD hats to help the community. In his professional life Remko is an Unix Engineer for Snow B.V. in the Netherlands mostly focussing on Firewalls and Security (Checkpoint/Juniper etc.). You can contact him by sending an email to: [email protected], or if you want to hire him send an email to [email protected] or check out their website on: http://snow.nl
The more time passes with tarsnap, the more impressive it is.
Following is a list of all my privately used systems (2 machines which only host jails — here named Prison1 and Prison2 — and several jails — here named according to their functionality) together with some tarsnap statistics. For each backup tarsnap prints out some statistics. The amount of uncompressed storage space of all archives of this machine, the compressed storage space of all archives, the unique uncompressed storage space of all archives, the unique compressed storage space of all archives, and the same mount of info for the current archive. The unique storage space is after deduplication. The most interesting information is the unique and compressed one. For a specific archive it shows the amount of data which is different to all other archives, and for the total amount it tells how much storage space is used on the tarsnap server. I do not backup all data in tarsnap. I do a full backup on external storage (zfs snapshot + zfs send | zfs receive) once in a while and tarsnap is only for the stuff which could change daily or is very small (my mails belong to the first group, the config of applications or the system to the second group). At the end of the post there is also an overview of the money I have spend so far in tarsnap for the backups.
Attention: the following graphs are displaying small values in KB, while the text is telling about sizes in MB or even GB!
The backup of one day covers 1.1 GB of uncompressed data, the subtrees I backup are /etc, /usr/local/etc, /home, /root, /var/db/pkg, /var/db/mergemaster.mtree, /space/jails/flavours and a subversion checkout of /usr/src (excluding the kernel compile directory; I backup this as I have local modifications to FreeBSD). If I want to have all days uncompressed on my harddisk, I would have to provide 10 GB of storage space. Compressed this comes down to 2.4 GB, unique uncompressed this is 853 MB, and unique compressed this is 243 MB. The following graph splits this up into all the backups I have as of this writting. I only show the unique values, as including the total values would make the unique values disappear in the graph (values too small).
In this graph we see that I have a constant rate of new data. I think this is mostly references to already stored data (/usr/src being the most likely cause of this, nothing changed in those directories).
One day covers 7 MB of uncompressed data, all archives take 56 MB uncompressed, unique and compressed this comes down to 1.3 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/named, and /var/db/mergemaster.mtree.
This graph is strange. I have no idea why there is so much data for the second and the last day. Nothing changed.
One day covers 8 MB of uncompressed data, all archives take 62 MB uncompressed, unique and compressed this comes down to 1.5 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/spool/postfix, and /var/db/mergemaster.mtree.
This looks not bad. I was sending a lot of mails on the 25th. And the days in the middle I was not sending much.
One day covers about 900 MB of uncompressed data, all archives take 7.2 GB uncompressed, unique and compressed this comes down to 526 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mergemaster.mtree, /home (mail folders) and /usr/local/share/courier-imap.
Obviously I have a not so small amount of change in my mailbox. As my spamfilter is working nicely this is directly correlated to mails from various mailinglists (mostly FreeBSD).
One day covers 100 MB of uncompressed data, all archives take 801 MB uncompressed, unique and compressed this comes down to 19 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mysql and /var/db/mergemaster.mtree.
This is correlated with the use of my webmail interface, and as such is also correlated with the amount of mails I get and send. Obviously I did not use my webmail interface at the weekend (as the backup covers the change of the previous day).
One day covers 121 MB of uncompressed data, all archives take 973 MB uncompressed, unique and compressed this comes down to 33 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mergemaster.mtree, /usr/local/www/horde and /home.
This one is strange again. Nothing in the data changed.
One day covers 10 MB of uncompressed data, all archives take 72 MB uncompressed, unique and compressed this comes down to 1.9 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mergemaster.mtree and /var/db/samba.
Here we see the changes to /var/db/samba, this should be mostly my Wii accessing multimedia files there.
One day covers 31 MB of uncompressed data, all archives take 223 MB uncompressed, unique and compressed this comes down to 6.6 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg and /var/db/mergemaster.mtree.
This is also a strange graph. Again, nothing changed there (the cache directory is not in the backup).
One day covers 44 MB of uncompressed data, all archives take 310 uncompressed, unique and compressed this comes down to 11 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mergemaster.mtree, /home and /usr/local/www/phpMyAdmin.
And again a strange graph. No changes in the FS.
One day covers 120 MB of uncompressed data, all archives take 845 MB uncompressed, unique and compressed this comes down to 25 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mergemaster.mtree, /usr/local/www/gallery2 and /home/gallery (excluding some parts of /home/gallery).
This one is OK. Friends and Family accessing the pictures.
One day covers 7 MB of uncompressed data, all archives take 28 MB uncompressed, unique and compressed this comes down to 1.3 MB. This covers /etc, /usr/local/etc, /root, /var/db/pkg, /var/db/mergemaster.mtree, /space/jails/flavours and /home.
This one looks strange to me again. Same reasons as with the previous graphs.
One day covers 56 MB of uncompressed data, all archives take 225 MB uncompressed, unique and compressed this comes down to 5.4 MB. This covers /etc, /usr/local/etc, /usr/local/www/postfixadmin, /root/, /var/db/pkg, /var/db/mysql, /var/spool/postfix and /var/db/mergemaster.mtree.
This graph looks OK to me.
One day covers 59 MB of uncompressed data, all archives take 478 MB uncompressed, unique and compressed this comes down to 14 MB. This covers /etc, /usr/local/etc, /root, /home, /var/db/pkg, /var/db/mergemaster.mtree, /var/db/mysql and /var/spool/ejabberd (yes, no backup of the web-data, I have it in another jail, no need to backup it again).
With the MySQL and XMPP databases in the backup, I do not think this graph is wrong.
The total amount of stored data per system is:
Since I use tarsnap (8 days), I have spend 38 cents, most of this is bandwidth cost for the transfer of the initial backup (29.21 cents). According to the graphs, I am currently at about 8–14 cents per week (or about half a dollar per month) for my backups (I still have a machine to add, and this may increase the amount in a similar way than the Prison1 system with 2–3 jails). The amount of money spend in US-cents (rounded!) per day is:
I started looking if there is a way to port the Chromium browser (aka the open-source core of the Google Chrome browser) to FreeBSD but it looks like someone has already done it :) Download Chromium for FreeBSD here!
>Since I lent my RS232/USB adapter to a friend it was nice opportunity to experiment with Flyswatter on-board RS232 port. OS X does not support FTDI devices out of the box, but it's not a problem for OpenOCD, which uses generic interface to communicate JTAG board. Things get a little bit more complicated when you're trying to get on-board RS232 port working.
I started with installing stock drivers from FTDI site. Current version supports Snow Leopard. With these drivers installed system started to detect two COM ports but JTAG part stopped to work as OpenOCD failed to claim USB device.
Long story short: you'll need to edit kext content to prevent first usb device from being recognized as a virtual COM port. Nothing fancy, simple text editor would do the trick for all you need to edit is plain XML file. Find line <key>FT2232C_A</key> and delete it along with following <dict> element. Reload kext using kextunload/kextload and voila - JTAG works, "cu -s 115200 -l cu.usbserial-FS000000B" works.
At work (client site) SUN made a presentation about their OpenStorage products (Sun Storage 7000 Unified Storage Systems) today.
From a technology point of view, the software side is nothing new to me. Using SSDs for zfs as a read-/write-cache is something we can do (partly) already since at least Solaris 10u6 (that is the lowest Solaris 10 version we have installed here, so I can not check quickly if the ZIL can be on a separate disk in previous versions of Solaris, but I think we have to wait until we updated to Solaris 10u8 until we can have the L2ARC on a separate disk) or in FreeBSD. All other nice ZFS features available in the OpenStorage web interface are also not surprising.
But the demonstration with the Storage Simulator impressed me. The interaction with Windows via CIFS makes the older version of files in snapshots available in Windows (I assume this is the Volume Shadow Copy feature of Windows), and the statistics available via DTrace in the web interface are also impressive. All this technology seems to be well integrated into an easy to use package for heterogeneous environments. If you would like to setup something like this by hand, you would need to have a lot of knowledge about a lot of stuff (and in the FreeBSD case, you would probably need to augment the kernel with additional DTrace probes to be able to get a similar granularity of the statistics), nothing a small company is willing to pay.
I know that I can get a lot of information with DTrace (from time to time I have some free cycles to extend the FreeBSD DTrace implementation with additional DTrace probes for the linuxulator), but what they did with DTrace in the OpenStorage software is great. If you try to do this at home yourself, you need some time to implement something like this (I do not think you can take the DTrace scripts and run them on FreeBSD, this will probably take some weeks until it works).
It is also the first time I see this new CIFS implementation from SUN in ZFS life in action. It looks well done. Integration with AD looks more easy than doing it by hand in Samba (at least from looking at the OpenStorage web interface). If we could get this in FreeBSD… it would rock!
The entire OpenStorage web interface looks usable. I think SUN has a product there which allows them to enter new markets. A product which they can sell to companies which did not buy something from SUN before (even Windows-only companies). I think even those Windows admins which never touch a command line interface (read: the low-level ones; not comparable at all with the really high-profile Windows admins of our client) could be able to get this up and running.
As it seems at the moment, our client will get a Sun Storage F5100 Flash Array for technology evaluation in the beginning of next year. Unfortunately the technology looks to easy to handle, so I assume I have to take care about more complex things when this machine arrives… 
The FreeBSD Foundation is kicking off their End-of-Year Fund Raising Drive! Their goal this year is to raise $300,000. So far, they have raised just over $159,000 so they are little more than half way towards their goal. Please consider making a donation and help spread the word by tweeting and blogging about the drive.
Click here to find out how to make a donation.
I am impressed. Yes, really. It seems tarsnap DTRT.
I made a test with tarsnap. I made a backup of some data (a full backup of everything is kept on a ZFS volume on an external disk which is only attached to make a full backup once in a while) of one of my systems. This data is 1.1 GB in size (most of it is /usr/src checked out via subversion and extended with some patches — no music, pictures or other such data). This compresses down to 325 MB. Of this 325 MB of data only 242 MB is stored encrypted on the tarsnap server (automatic de-duplication on the backup client). The second backup of the same data in the following night (again 1.1 GB in total, 325 MB compressed) caused 216 kB of new data to be stored on the tarsnap server (again, de-duplication on the client). What I have now are two full off-site backups of this data (two archives with 1.1 GB of data after decompression), with the benefit that the additional storage space required is the storage space of an incremental backup.
The cost (in dollar) of this so far is 0.074603634 for the initial transfer of the data, 0.00242067783 for the data storage on the first day, plus 0.0019572486 for the transfer for the second backup. From the initial 29.93 I still have 29.85 (rounded) left. If I factor out the initial transfer and assuming that the rate of change for this system stays constant, this comes down to 0.01 (rounded-up) per day for this system (or about 8 years of backup if I do not add more systems and do not add more than the initial 29.93 (= EUR 20) — and the price of this service does not increase, off course). Is this data worth 1 cent per day for me? Yes, for sure! Even more, but hey, you did not read this here. 
That is what you get when a person designs a service which he is willing to use himself for a price he wants to pay himself (while still not lose money with the service).
Colin, again, I am impressed. Big thumbs up for you!
Now I just have to add some more systems (/etc and similar of various jails… and of course the data of this blog) and polish my tarsnap script for “periodic daily” .
P.S.: Yes there are also places to improve, I found already some things (the config file parser is a little bit strict what it accepts, and some things should be more documented) but Colin is responsive and open to improvement suggestions.
I finally have a VMWare ESX 4 (vSphere 4) in production and it's time to see how much we lost this time in the name of greater flexibility. In short: the usual (which is a lot).