Friday, May 26, 2017

How to upload images to a specific album in Google Photos

How to upload images to a specific album in Google Photos:

  1. Create the album. You have to choose an existing photo to create it.
  2. Drag and drop the photos you want to upload onto the album you’ve created.

Despite years of customer requests you still can’t select a folder and upload it into an album.

I’ve read that if you work with full res (not reduced) images in Google Drive you can organize them in folders and turn those folders into albums in Google Photos. These count against storage costs. I have not tested this.

Saturday, May 20, 2017

Aperture crash - sad day for my iCloud Photo Share streams (shared albums)

Aperture locked up when duplicating an image. I had to force quit, when I restarted I rebuilt the database. 5,300 images showed up as recovered.

Turns out they were all thumbnails for iCloud shares, but they’d lost connection to iCloud. When I deleted them I found most of my iCloud share streams were empty.

I believe I have my images, but it is sad to lose the relationship to the shares. Aperture is no longer supported by Apple of course. I’m running El Capitan, for what that’s worth.

Backups are no help of course. Even if I could recover the relationship to photos shared in iCloud I’d lose other work.


/Users/jfaughnan/Library/Application Support/iLifeAssetManagement/assets/pub has 7.5GB of files holding 2,634 items including some photo stream temp files. It’s not clear if this can be deleted, but it may be Aperture doesn’t use it…

Sunday, May 14, 2017

There may be a fatal flaw in my backups. (actually, no)

I’m leaving this one up as a reminder of how scary the world of secure backups is, and how important it is to actually do a dry run of a disaster recovery scenario.

This is the original post. It’s wrong:

Don’t every tell me backup is a solved problem.

I have offsite backups of my data. Two offsite and two onsite Carbon Copy clones that I rotate. In addition to my onsite Time Machine backups.

All encrypted of course, because otherwise that would be terrible.

Great. All set. If the house burns down we’ll have our data (assuming we still need it).

Except those drives are whole drive encrypted with FileValue 2. So each has a unique recovery key. A recovery key that is different form each backup drive and can only be known at the time of encryption. A recovery key that is stored in a keychain on my MacBook. A device that can be lost.

I’d be better off if that recovery key were in iCloud, but I don’t think it is. Or I could follow Apple’s complex directions for managed recovery keys. Or I could have created encrypted sparse image folders for CCC, I’d know the image password then. Or maybe created bootable encrypted disk backups.

I have a bad feeling I don’t really have backups at all.

There’s a fine line between security that makes data inaccessible to bad actors and security that makes it inaccessible to everyone.

I hope I am wrong about this.

It’s wrong because FileValue 2 whole drive encryption actually behaves like the disk image encryption I’m familiar with. I was confused by the Recovery Key complexity. Doing a dry run of disaster recovery shows what happens.

I mounted one of my encrypted backups using my Voyager cradle and a USB 3 to UBS 2 cable with an old Air. I was asked for the password I’d used to encrypt the drive, not for the recovery key. I was able to mount my backups just as I would on any foreign Mac.

That password is the same for all my backup images and it’s stored in 1Password as well as printed. I’m going to add it to the Dead Man / post-mortem document I keep in Google Drive that’s shared with several trusted people.

False alarm. Need more coffee.

See also