I recently created a virtual machine and installed iTunes. I then proceeded to download some videos from iTunes U, but every time the video had been downloaded it disappeared. iTunes was showing the videos as downloading, I could tell it was being downloaded as a “download.mov” file was appearing in the “Downloads” directory underneath “iTunes\iTunes Media”. I first thought it might be a permissions issue as the iTunes library is on a file server, but even giving full rights to the relevant directories made no difference. Searching the internet I found a thread named “podcasts are downloaded but disappear afterwards” on Apple’s support forum. The problems mentioned were the same as mine. One of the posts suggests to “Update QuickTime to the latest version and the video downloads will appear.”
Interesting, I did not have Quicktime installed at all, I only need iTunes to select and download relevant videos, I’ll be watching them elsewhere (using xbmc). So I installed Quicktime, and lo and behold, the downloads no longer disappear. How odd that iTunes does not complain about Quicktime being absent.
Mat Honan lost all of the data on his iPhone, iPad and his laptop the other day (How Apple and Amazon Security Flaws Led to My Epic Hacking and Video: Mat Honan Details His Post-Hack Paranoia). And he didn’t have a backup: “Had I been regularly backing up the data on my MacBook, I wouldn’t have had to worry about losing more than a year’s worth of photos, covering the entire lifespan of my daughter, or documents and e-mails that I had stored in no other location.”
The day after, Steve Wozniak warned about cloud services in general (Is Woz Right? Will the Cloud Shift be ‘Horrendous’?), and this inspired a post from Cringely (A belt and suspenders for your cloud storage) which is primarily a post about backing your stuff up, because you can’t necessarily trust the integrity of your data to “the cloud”.
I recently finalised a setup I’m happy will offer me quite a lot of protection. I have now for many years had a home server, in its latest incarnation it is based on Ubuntu Linux. The various laptops in my home synchronise their document libraries with the server every now and then. The hard disks in the server have almost always been in a RAID array. My current server has 4 disks of 2 TB each. The RAID 5 setup I use means that I have 6 TB disk space available out of the 8 TB in the server.
That RAID 5 setup is level 1 of my data protection system. I agree with others that protecting your data using RAID cannot replace a backup. If you delete a file from your disk, it is gone, or if a software bug modifies a file RAID will do as it is told and write the changes to the disks. It will however ensure that any data created or modified since my last backup won’t be wiped out by a single disk failure. More importantly, it means I don’t have to rush out to buy a new disk and restore everything the minute a disk fails, I’ve bought myself some time, but that advantage has nothing to do with my data security.
of my data protection system are my external hard disks. They regularly back up everything on the online disks, and the backup is quite quick because the data transfer is local. I have a lot of media (movies, photos, music) on those disks, and although I still have the DVD’s and CD’s with the original movies and music they are not really part of my backup strategy, the time it would take to rip all the DVD’s and CD’s again and adding all the right meta data to the music files is prohibitive. So that means I need a lot of external disks. But my digital life would not be ruined if I lost the movies and music. My documents and my photos however, that is another matter, so therefore I have two external disks I alternate with to back up that data. So if we consider a photo that is not extremely new, I have a copy so far in three places; on the server and on two different external disks. But what would happen if my house burned down, all my data would still be gone even though I had a backup.
of my data protection system is offline storage. Cringely has a small server under a bed in his mother-in-law’s house. I used to alternate with some external disks I would ask friends if I could store with them, but you end up with external disks that were last backed up ½ a year ago and that just isn’t good enough. So I use Crashplan for my offsite backup. The disadvantage of a cloud backup system is first that it can’t be stand-alone as a backup strategy. That is what Mat Honan discovered. His latest photos were backed up in iCloud. That is what Wozniak’s and Cringely’s comments are all about. But as a level 3, if all else fails, I trust it enough for that. The second disadvantage is speed (at least with my internet bandwidth it is). When I initially installed Crashplan on my server I first had it backup my photos, then my document, then my music, and it is currently backing up my movies. I probably don’t really need to do that, but Crashplan offer unlimited storage so why not. After 7 months, I’ve backed up 1.6 TB to “the cloud”. Another 2.4 TB to go…
All in all, I feel my data is pretty safe from accidental or deliberate deletion, and hard disk failures. Over the years, I’ve reinstalled the operating system on my server(s) a couple of times, so I know I can get my data back from my local backup. I have tried to restore selected files from Crashplan and that works too. I realise that it would take a long time if I ever needed to do a complete restore of my data from Crashplan, but that would only be a requirement in the very worst of cases. In such a case the fact that I even have a backup would be considered a bonus. I do of course hope that in such a case “the cloud” would not let me down.
Am I totally protected against data loss? No, bit rot can still do (and has done) data corruption, but that will be the subject of another post
Back in February, I asked if Crashplan had crashed. A few days after my post there was a review of Crashplan on AllthingsD. The “negativity” of my post probably deserves a follow-up. As I wrote in that post, I was probably going to subscribe to the Crashplan service after my free trial period anyway, and I did. In fact I went for the 4-year family subscription. The PC’s of my parents and my brothers are now all backed up, albeit that is a bit too late for my father who had a hard disk failure in his laptop last year and he had no backup. In my previous post I pointed out that I would not be paying Rolls-Royce prices for the service and I therefore couldn’t expect Rolls-Royce service. Overall the service has performed well. My main gripe is (as it was in my previous post) that when there are unforeseen issues, the lack of information from Crashplan is disconcerting. I can sort of understand that. With the very low price they charge, too much time spent by a supporter explaining to me what is going on can quickly wipe out any revenue they get from my subscription. Nevertheless, I wish they were more open about why the service may be behaving the way it is at times. I’m not expecting perfect service from the service itself, and the lack of information the few times I wish there had been an issue does leave me with a bit of unease. Overall I would recommend Crashplan for offline storage.
Phase 2 of the Hannington transmitter switchover has been done, and there are no longer any analogue TV signals transmitted, so except for one MUX, all the others have changed frequencies and where I live I can now watch Freeview HD. I have had a previous post about the changes that need to be made if, like me, you get some of your TV services via a Linux computer using TVHeadend, MythTV or similar.
The following is what should be in an updated /usr/share/dvb/dvb-t/uk-Hannington file:
# UK, Hannington # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 666000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # BBCA MUX T 642000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # D3+4 MUX T 618167000 8MHz 2/3 NONE QAM256 32k 1/128 NONE # BBCB MUX (DVB-T2, HD channels) T 634000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # SDN MUX, not sure if fec_hi should be 2/3 T 658000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # ArqA MUX, not sure if fec_hi should be 2/3 T 682000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # ArqB MUX
If, like me, you use tvheadend, you will need to create all the Multiplexes manually. Using the data above, this is what you will need to enter:
Frequency (kHz): <field 2 if you count the first ‘T’ as field 1, remove the last three zero’s>
Bandwidth: 8 MHz
Constellation: <field 6>
Transmission mode: <field 7>
Guard interval: <field 8>
FEC Hi: <field 4>
FEC Lo: <AUTO or NONE, not quite sure, I entered AUTO and it works here>
These data have been valid since February 22, and I have no information about when or if they might change. In April some of the multiplexes will have their transmitting power increased, but this will not require any changes to the above.
If, like me, you get some of your TV services via a Linux computer using TVHeadend, MythTV or similar, you will possibly need to know a few technical details to get your system to retune after phase 1 of the switchover for the Meridian region. I personally use TVHeadend and these are the details I had to enter:
Frequency (kHz): 666000 Bandwidth: 8 MHz Constellation: QAM-64 Transmission mode: 8k Guard interval: 1/32 Hierarchy: None FEC Hi: 2/3 FEC Lo: 2/3
Whilst adding the details for the MUX that was moved, you might also want to remove the details for the “B” MUX (on 674.2MHz) as the channels located there are now all also on the moved (now called PSB1) MUX.
You may also want this updated uk-Hannington file. I’ve taken the one which on my Ubuntu system was located in /usr/share/dvb/dvb-t and modified it.
# UK, Hannington # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy # This is the MUX that was moved on February 8th #T 706000000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # Moved MUX T 666000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 650167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE T 626167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE # The channels on this MUX are now duplicates of channels also available on the moved MUX #T 674167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE T 658167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE T 634167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
The details here are only valid from February 8th and until February 22′nd 2012 when a new retune needs to be performed.