Restoring gets hung up on a week (Red Exclamation Point)

I backed up fully. Restoring to a new iPhone and moved the “Previous Backup xxxxxxx” file into the import folder and then began manually restoring by clicking “Import All”.

I may have done something else that I don’t recall but I do think I did this wrong. For some reason now the restore process gets hung up.

Then I referred to these forums and remembered how to restore properly.

Now I am getting the pink prompt at the top of the app but the same thing happens, it gets hung up and 2024_W09 and 2024_W01.

I really hope I did not corrupt anything. I have tried manually skipping around the locomotion weeks to restore but they all come up with a red exclamation point

I have multiple “previous backups” from years prior stored elsewhere in iCloud, can they be used to restore first and then add on with newer backups?

Any help would be greatly appreciated!

–Tristan


This is week 09 error when I click the exclamation point.
How badly did I damage my backups??

Hi @TristanP335!

The red exclamation mark means there was an error (or errors) when importing data in that file. Assuming these are week sample files, typically that could mean there was only one or two errors, with samples not importing due to their parent timeline item’s file being missing, or the item’s associated place file being missing.

You can tap on the red exclamation mark to open a details view which should list th error, what was imported, what was skipped, etc. And on that view there will be a button titled “Retry import ignoring missing dependents”. Tapping that will reattempt the import of that file, and importing the samples regardless of whether their parent item file is there or not.

By doing that you get the raw recorded data back in, so nothing of the recorded data is lost. Though it will mean that the processing engine will need to recreate the timeline items around the samples, probably not getting their start and end points exactly the way you wanted or had them previously, and losing details like assigned places. That’ll mean there’ll be some cleanup work to do.

Oh but it doesn’t sound like you’ve done anything wrong! With the File Importer view you can’t technically do anything fully “wrong”. Whatever you tap it’ll attempt to import that, if it can, while also avoiding clobbering any more recent data already in the database.

But there is a preferred pattern: Only tap on the sample week files - the others (items, places) will get imported automatically, as dependents of the samples. And do the sample files in order from newest to oldest, without skipping weeks. If you skip weeks it can potentially cause problems with the processing engine when you view those gaps in timeline view.

Oh and you can “Import All” on notes and summary files at any point, before or after or during anything else. Those ones aren’t linked or dependent in any way, and can be imported whenever, without trouble.

If you manage to get everything in after using the “Retry ignoring missing” button, but the timeline views then look weird or incredibly wrong in some places, it might be best to delete the app and start again, with next time attempting to get the weeks all imported from newest to oldest, in case that helps. Though as long as you don’t go poking about in timeline views too much while the import is happening it tends to not matter too much.

Oh and for the older Previous Backups folders you have, yes you can also import from those too! I would say that you could import them from oldest to newest folders, each over top of the previous, and that should all just work. But in practice I worry that there’ll be gaps in the import logic that don’t account for some clashes with older data and newer data. It’s something I haven’t tested extensively. So it’s one of those “on paper it all should work” but “in practice… I’m nervous”.

Let me know how you get on! If necessary we could attempt to fill in the missing gaps (eg missing item or place files) by finding the relevant ones in older Previous Backups folder. Though that’d be painfully fiddly work, so you might be better off just getting all the samples imported then doing the necessary cleanup in edit views / timeline views until you get it back to a happy state. Will have to feel it out and see how it goes.

Thank you for this!

This will be a for parter, and I apologize for the lengthiness of it.

I searched my Mac for the missing files in the error log and found them in my alternative backup folder. For example this missing file ‘52CF8F51-421F-423F-8CAE-28666CE132FF’ was found under “Timeline Item” in a folder called “52”

‘/Users/tristan/Library/Mobile Documents/com~apple~CloudDocs/Tristan Cloud/Computer Stuff/ARC Backups/Previous Backups C064A115/TimelineItem/52/52CF8F51-421F-423F-8CAE-28666CE132FF.json’

MISSING JSON FILES FOUND
Can I do one of he following:

  1. Copy that .JSON file into the folder 52 in the currently restoring backup in the app, which would take alot of time locating and moving each one.
  2. In that case, can I move folder 52 and replace it or merge the one restoring with an alternative?
  3. Moving up the hierarchy, what if I replaced or merged the ENTIRE “TimelineItem” folder with the one in my alternative backups that appears to have all of the missing files

IMPORTING MULTIPLE RESTORES
Also, in regard to restoring from older backs to newer ones, can I have more than one restore folder at a time? OR should place them in the IMPORT folder one by one?

ARC INTELLIGENCE
I would also like to take this opportunity ask two other questions.

Does Arc know to preserve the latest data? Meaning during the restore process, will it be able to find recent changes I may have made to past locations and events? Therefore, by restoring old backups, newer ones will know to correct the changes.

BACKUP NAMING
This is something I should’ve asked a long time ago, but better late than never. What is the difference between a “Backup” folder and a “Previous Backup xxxxxxx” folder? When installing arc on a new phone, does it take the backup folder and then rename it as previous backup and then create a new backup folder? I assume that’s how it works.

As always, thank you!

1 Like

Yep, you definitely can do that! That would be ideal. Though as you say, potentially tedious if there’s a lot of them.

It would be best to only copy over the missing ones from the older Previous Backups folder. If you replace existing item files in there with older ones from an older backup that could confuse things during restore.

If it could be done by only filling in missing files, then yes. But I don’t know of a way to do that without doing some shell scripting, which could get quite fiddly. You could probably get one of the robots (my preference being Claude or o1, for lowest risk of subtle mistakes) to write up a script for it. Would just need to make sure it definitely knows exactly what’s needed - no overwriting of existing files, only copying over ones that exist in the older backup but not the newer.

Oh, but a thought comes to mind: It could easily be that only a small number of item files are missing. Like one or two per week that errored. So it could be simplest and fastest to just track down the missing ones in older backups and copying those over manually.

Usually what’s happened is the last time the backups task ran it didn’t quite get to finish the job, so while 99.99% of the data is there, there’s a small handful of objects that didn’t make it. They’d get there during the next scheduled backups run, but then that one might also get stopped by iOS before it quite finishes. So each time there’s potentially a small number of bits missing that changed since the previous backups run - nothing serious, just enough to make the restore annoying.

One at a time. I’m not sure what the File Importer view would do if there’s multiple ones in there. I suspect it’d just get confused and do the wrong thing. It’s only built for expecting one at a time at the moment.

Yep. Exactly. On every object in the backups it looks at the “lastSaved” date and compares it to the existing object in the db (if there is one), then only imports it if it’s newer than the existing one. You can notice this happening if you tap a samples week file again that’d already imported. It’ll zip through and finish in seconds, because everything in it already existed and had same or newer lastSaved dates, so there was nothing to do.

That’s also why I say technically restoring multiple Previous Backups folders, one after the other, from oldest to newest, should work fine. But it also ups the complexity of the process quite a bit, with the system dealing with a much higher ratio of existing data. So then there’s the question of whether there are any rare edge cases that the importer code/logic has missed?

I don’t think so, and in my testing I haven’t found any. But I’m just one guy, and there’s plenty of chance for me to have missed things, not thought of edge cases so didn’t even realise I needed to test for them, etc. I don’t want to send you off with “yeah for sure, that’ll work perfectly” when it’s something I haven’t extensively tested myself. I’ve tended to focus my testing on either full fresh restores of entire backups, or small targeted imports of small numbers of modified files.

Yep exactly. When the app is freshly installed it checks the iCloud Drive folder, and if it finds an existing Backups folder it renames it to “Previous Backups [random chars]”.