IPhone – How to get rid of the encrypted iPhone backups to start from scratch

Things you can try (that I haven't tried myself), other than hoping it's not an Apple bug:

• If you have a 4 digit lockcode on the iPhone, the encryption on iTunes might share the same password. Try the same pin. Also try older pins, if you change it. It could be an old one.
• Get iPhone Explorer, delete /var/Keychains/Keychains-2.db (may need to jailbreak the phone to be able to see it) on it and restart. Be aware this will clear all your passwords. Now delete your iTunes encrypted backups and re-sync.
• Enter DFU mode, wipe your phone, and sync back - this is an easy way to remove the lock code, not sure about the encrypt iphone check tho. Probably.
• Use some mysterious magic tool, enter in recovery mode to begin with a lot more of hacking. I won't get into much detail here because this isn't a simple procedure. You're on your own. Just wanted to cite it's possible and that maybe even today the "encryption" is quite fake.
• Restore from an old unencrypted backup. Yes, this is the closest step to "wipe".
• As you already suggested, wipe your phone (just for the sake of completeness).

Good luck!

Proposed solution:

You have an Amazon EC2 instance, with elastic block store large enough to hold the whole of the image you intend to backup:

backup-host.yourdomain.com:
/mnt/EBS/my-desktop-backup/coreimage.dmg
/mnt/EBS/my-laptop-backup/coreimage.dmg

Where:

/dev/ebs-disk-001 -> /mnt/EBS/my-desktop-backup
/dev/ebs-disk-002 -> /mnt/EBS/my-laptop-backup
etc.
etc.

or

backup-host.yourdomain.com:
/mnt/EBS/my-desktop-backup_coreimage.dmg
/mnt/EBS/my-laptop-backup_coreimage.dmg

Where:

/dev/ebs-disk-001 -> /mnt/EBS

Your initial backup would take a long while to sync, but if you employ rsync to sync, then you can eventually have the remote image catch up to your local image's changes.

Once it is caught up, you can then initiate an EBS snapshot on Amazon's side for the EBS volume containing your encrypted image.

Rinse and repeat for each backup period + snapshot you want to have backed up to the remote server, taking the following items/requirements into account:

• The Encrypted Image needs to be unmounted.
• The remote image copy needs to be 100% synced with the unmounted local image.
• The snapshot needs to be done with the remote EBS volume sync'd, filesystem buffers flushed, and with no changes pending.

With this, you will be able to do the incremental backups using Amazon's cloud technology.

S3 has some serious limitations, which would not suit your needs, for this particular purpose.

The EC2 instance, if fully backed by EBS, can be shut down when you are not doing a remote sync. Ie, when your backup kicks off, you can have it fire up the instance via Amazon's EC2 API, and get the dynamic name or IP address. Once it confirms it is up, it can kick off the rsync backup. When done, it can shutdown the remote image and initiate an Amazon EBS volume snapshot action.

Edit:

rsync does chunk/block level diffs for larger files. You can specify the size of the block diff:

--block-size=SIZE

You can also specify the data stream being sent to the remote server to be compressed, saving you on traffic.

Caveats about S3 vs EBS:

Unless the solution you employ supports splitting the single large file into segments and sending them in parallel, Amazon S3 throttles the data being sent down to under 400KB/sec after a certain size.

I employ rsync differential backups on my servers to S3 as compressed tarballs. Even at tarball sizes of about 500MB, S3 will throttle. In order to work around this, you need to split the file you are sending up into parts, otherwise, the backup to S3 will take forever.

Whereas an EC2 instance with EBS volumes will be faster and not require the need to split files, simplifying backup and restoration.