iCloud.com gains options to restore files, contacts & calendar data

Posted:
in iCloud edited August 2015
Without fanfare, Apple recently updated iCloud.com to allow users to restore files, contacts, and/or calendars and reminders hosted on the service, opening up a recovery window for mistakes.




The options are hidden under the Settings app on the website. In each case, different limits apply. Deleted files for example are kept on Apple's servers for varying amounts of time, though apparently no more than 30 days. Recovered files appear in iCloud Drive.

Contacts can only be restored as an archive, not individually, and doing so will revert contacts across every device signed into the same iCloud account. This creates an archive of the latest contact data though, making it possible to undo the restore.

A similar system is in effect for calendars and reminders. Apple cautions that all sharing will be stripped out during a restore, forcing users to once again offer or ask for permissions. Any scheduled events will be canceled and recreated, which could cause confusion as invited guests will see both cancellation notices and new invitations.

Because they weren't announced it's not clear when the restore options were added, although they appear to have surfaced sometime this week.

Apple has been gradually developing iCloud.com into a comprehensive platform, one major addition in the past year being iCloud Photo Library. The Web versions of Pages, Numbers, and Keynote are still in beta however, despite having been online since 2013.
«1

Comments

  • Reply 1 of 22
    How about "Restore my iTunes library that got corrupted by Apple Music"?
  • Reply 2 of 22
    I'd be willing to bet that Apple has been migrating iCloud function to FoundationDB.

    This adds flexibility, accessibility, reliability, scalability and performance.

    In re: flexibility, FoundationDB allows you to define a DB accessed as an hierarchical data structure -- mimicking the folder/file tree of the Finder.

    This would facilitate a [B][I] Time Machine [/I][/B] implementation in iCloud -- for iDevices and Macs, alike.
     
  • Reply 3 of 22
    This would facilitate a Time Machine implementation in iCloud -- for iDevices and Macs, alike.
     

    My thoughts exactly.
  • Reply 4 of 22
    I wonder if Apple could offer an option for iCloud with no new features, except that it just works on a consistent basis?
  • Reply 5 of 22
    solipsismysolipsismy Posts: 5,099member
    It's about damn time! This article doesn't seem to elucidate on if edited files can be restored to an earlier edit and, if possible, how long those edits are available. I'd hope that it's at least 30 days for free accounts and indefinitely for paid accounts, just like with Dropbox.

    I'd also like this feature to be available in iCloud Drive on Mac OS X and iOS, not just via the webapp. This would go a long way to helping me pull the plug on using Dropbox for storage if they can achieve this goal.

    slprescott wrote: »
    How about "Restore my iTunes library that got corrupted by Apple Music"?

    You pay for enough cloud storage to have have your entire iTL saved on iCloud? At 1TB your ITL is small. Personally, I would suggest being more proactive by using a backup service instead of a syncing service. I recommend Time Machine for those using Macs that need something easy to use. An external 2.5" 1TB HDD for your Mac or if your router has a USB port that allows mounting of a drive should do you just fine.
  • Reply 6 of 22
    This would facilitate a Time Machine implementation in iCloud -- for iDevices and Macs, alike.
     

    My thoughts exactly.


    I would kill (well maybe just maim) to be able to install/test FoundationDB on my Mac -- using Swift, of course.

    Sigh ... I learned about FoundationDB when Apple acquired them & all downloads were removed from the FoundationDB site.

    I've been Playgrounding around with how to approximate the FoundationDB data structure -- an ordered Key/Value Pair.

    In Xcode you can do this by creating an ordered array that references an unordered dictionary.

    It appears to be quite flexible!
  • Reply 7 of 22
    mdriftmeyermdriftmeyer Posts: 7,291member
    I'd prefer Apple use PostgreSQL 9.5 for its backend services.
  • Reply 8 of 22
    I'd prefer Apple use PostgreSQL 9.5 for its backend services.

    Why? The last time I looked At PostgreSQL it was non-distributable -- the entire db had to reside on a server, and if replicated to other servers, there was no way to interface them through the db constructs.

    FoundationDB handles this easily and supports SQL Queries -- though not a relational db.

    If iCloud has millions of users with hundreds (or thousands?) of files each -- IDK if any relational db or single server could handle this.
  • Reply 9 of 22
    Hm. Sounds like a winner.

    If we assume for a moment that apple wants to store all your data in the cloud for backups and to distribute it "live" to various clients, might the next step be the reinvention of thin-clients, or chrome book done right?

    While I'm not sure what to feel about relying 100% on someone's cloud and the corresponding connection working reliably, I would love the idea of never having to worry about getting access to my data from anywhere and any kind of (apple) device, and beyond that like with iOS already don't really need to worry about the OS and file systems and disk space and some maintenance apart from installing updates.

    I think that, however, would take a few more years before it could see the light of day.
    And yes, I am aware, for the time being there are a number of use cases where you require raw computation power right at your desk.
  • Reply 10 of 22
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by Dick Applebaum View Post





    Why? The last time I looked At PostgreSQL it was non-distributable -- the entire db had to reside on a server, and if replicated to other servers, there was no way to interface them through the db constructs.

    Postges handles load balancing just fine. All load balancing database clusters work under pretty much the same principles. A cluster automatically designates a write master which is responsible for syncing data to the other members of the cluster. The other members are read only. If the master goes down, the member with the last write becomes the new write master. When the old master comes back online it will be a slave.

  • Reply 11 of 22
    solipsismy wrote: »
    You pay for enough cloud storage to have have your entire iTL saved on iCloud? At 1TB your ITL is small. Personally, I would suggest being more proactive by using a backup service instead of a syncing service. I recommend Time Machine for those using Macs that need something easy to use. An external 2.5" 1TB HDD for your Mac or if your router has a USB port that allows mounting of a drive should do you just fine.

    SolipsismY,

    Thanks for those good suggestions.

    (My orig post was somewhat tongue-in-cheek to reflect the experience of others; I didn't lose any music, that I know.)

    Question:
    My iTunes library is on an external drive, and I sync with that via my PC weekly. Is this configuration vulnerable to the iTunes library corruption that others reported (after turning on Apple Music), or does my physical copy of the music protect me from accidental loss?
  • Reply 12 of 22
    mstone wrote: »
    Why? The last time I looked At PostgreSQL it was non-distributable -- the entire db had to reside on a server, and if replicated to other servers, there was no way to interface them through the db constructs.
    Postges handles load balancing just fine. All load balancing database clusters work under pretty much the same principles. A cluster automatically designates a write master which is responsible for syncing data to the other members of the cluster. The other members are read only. If the master goes down, the member with the last write becomes the new write master. When the old master comes back online it will be a slave.

    In the scenario you describe above:
    1. does each cluster contain the entire db
    2. what is the maximum size of the cluster, the db
    3. what is the maximum I/O (TPS) of the write master
    4. can these clusters be distributed to say LA, SF, NYC, etc.
    5. can you have more than 1 write master


    Say, iCloud has millions of users with hundreds (or thousands?) of files each with hundreds or thousands of transactions per second.

    Can Postgres handle a database of that size? Can Postgres handle a tnsaction volume of that size?
    Foundation DB Key-Value Store Version 3.0 ran more than 14,000,000 random writes per second on a 32-machine cluster in Amazon EC2. Version 3.0's new monitoring capabilities improve ease-of-use and bring centralized database monitoring to FoundationDB. Admins can now monitor a database as a unit rather than each individual node in a cluster. FoundationDB can now centrally diagnose potential bottlenecks and pass that information to other monitoring infrastructures.

    http://www.tomsitpro.com/articles/foundationdb-nosql-database,1-2385.html


    These are honest questions! I read that Amazon, Google, eBay and others have requirements for massive, performant distributed databases that are far beyond the capabilities of today's relational db. That's why they rolled their own "NoSQL" solutions (or contract them from others).

    If Apple has big plans for iCloud services (and I think they do) -- then I think that their needs would be closer to Amazon, et al!
  • Reply 13 of 22
    SpamSandwichSpamSandwich Posts: 31,304member
    Quote:

    Originally Posted by Dick Applebaum View Post



    I'd be willing to bet that Apple has been migrating iCloud function to FoundationDB.



    This adds flexibility, accessibility, reliability, scalability and performance.



    In re: flexibility, FoundationDB allows you to define a DB accessed as an hierarchical data structure -- mimicking the folder/file tree of the Finder.



    This would facilitate a Time Machine implementation in iCloud -- for iDevices and Macs, alike.

     



    Presumably not for very large files, though. Sending or downloading hundreds of GBs or even several TBs can take a significant amount of time. I'm talking maybe a week or more in some cases.

  • Reply 14 of 22
    solipsismysolipsismy Posts: 5,099member
    slprescott wrote: »
    Question: My iTunes library is on an external drive, and I sync with that via my PC weekly. Is this configuration vulnerable to the iTunes library corruption that others reported (after turning on Apple Music), or does my physical copy of the music protect me from accidental loss?

    If it syncs both ways and the original data is overwritten, then, yes, it would be possible for one corrupt library to permanently affect other. This is why Time Machine is a decent solution for the consumer. Even if anything on your Mac gets corrupted, it's only from that backup forward that the corruption will be present. Any earlier backups can be accessed indefinitely unless your Time Machine drive runs out of space and it has to remove the old (good) backups to save the new ones. To help prevent that I would suggest a Time Machine that is at least 2x the size of your Mac's storage.
  • Reply 15 of 22
    I'd be willing to bet that Apple has been migrating iCloud function to FoundationDB.


    This adds flexibility, accessibility, reliability, scalability and performance.


    In re: flexibility, FoundationDB allows you to define a DB accessed as an hierarchical data structure -- mimicking the folder/file tree of the Finder.


    This would facilitate a Time Machine implementation in iCloud -- for iDevices and Macs, alike.
     
    Presumably not for very large files, though. Sending or downloading hundreds of GBs or even several TBs can take a significant amount of time. I'm talking maybe a week or more in some cases.

    Running Time Machine on a Mac the first time takes a lot longer too. But subsequent backups take a lot less time -- as they only backup changes since the last backup. And you can exclude portions of your file structure to start -- then add them in piecemeal, later.

    If Apple were to provide an iCloud Time Machine -- likely, they'd use a Percolate Up and Trickle Down strategy -- where as files are changed, they are backed up to the cloud -- and in the background is prioritized to backup all folders/files in the path to the changed file, more leisurely.
  • Reply 16 of 22
    solipsismysolipsismy Posts: 5,099member
    Running Time Machine on a Mac the first time takes a lot longer too.

    And the standard design means you can disconnect it from the back up at any time and it will pick up again when it's connected without having to re-backup any files that have had no changes sine the last attempt.
  • Reply 17 of 22
    solipsismy wrote: »
    Running Time Machine on a Mac the first time takes a lot longer too.

    And the standard design means you can disconnect it from the back up at any time and it will pick up again when it's connected without having to re-backup any files that have had no changes sine the last attempt.

    Yeah! IMO, Time Machine is one of the best Apple apps. IDK if they bought it or built it -- but it just goes along doing its thing.
  • Reply 18 of 22
    solipsismysolipsismy Posts: 5,099member
    Yeah! IMO, Time Machine is one of the best Apple apps. IDK if they bought it or built it -- but it just goes along doing its thing.

    As far as I can tell all the technology within for well-worn and use in the enterprise for awhile. Real genius seems to be from making it a standard consumer feature in their OS.
  • Reply 19 of 22
    mstonemstone Posts: 11,510member
    You can have clusters of clusters and the write masters will be in each data center for their own cluster. You can see this in action with Google if you get on the phone with a friend of yours on the other coast and you both search for the exact same terms and then look at how many results are returned, you'll notice there is a significant disparity between the two.

    Clearly there are different needs for different applications. In the case of Google they might not be concerned about the immediacy of their writes since mostly they're providing search results however in a situation where you're taking orders such as Amazon you may have to deploy a different strategy that can produce transactions quickly.

    There is no question that Foundation DB is a very efficient system. I was only pointing out that Postgres also has load-balancing as most enterprise database systems do.
  • Reply 20 of 22
    mstone wrote: »
    You can have clusters of clusters and the write masters will be in each data center for their own cluster. You can see this in action with Google if you get on the phone with a friend of yours on the other coast and you both search for the exact same terms and then look at how many results are returned, you'll notice there is a significant disparity between the two.

    Clearly there are different needs for different applications. In the case of Google they might not be concerned about the immediacy of their writes since mostly they're providing search results however in a situation where you're taking orders such as Amazon you may have to deploy a different strategy that can produce transactions quickly.

    There is no question that Foundation DB is a very efficient system. I was only pointing out that Postgres also has load-balancing as most enterprise database systems do.


    While quite long, this is a very revealing evaluation of the advantages for both NoSQL and RDMS. It was presented prior to FoundationDB gaining popularity.


    [VIDEO]



    Buried in there somewhere is a comment that some consider a major advantage to a NoSQL db is that there is no need for a DBA.

    Also he suggests that NoSQL can be used to advantage because of its immaturity -- to provide lower risk for quick-to-market business opportunities ...

    This reminds me of the success of VisiCalc in 1979 -- Departments needing IT (then called DP) services often had to wait 18-24 months to get their needs addressed. If you were trying to do a price/forecast of a new product coming to market in 6 months -- IT was of no use.

    Using the $79 VisiCalc app -- corporate departments would buy $2,500 plus of Apple ][ gear and run their forecasts starting the day they got the gear.
Sign In or Register to comment.