What is the best way to reconstruct / recover / restore a project that does not open anymore with a back up?

What is the best way to reconstruct / recover / restore a project that does not open anymore with a back up?

The actual project does not open anymore, so I want to get all of the changes / new files and folder / data made since that last back up was done to that back up to be it the actual project. What is the best method to do it?

What I would do is rename the broken project so it is clear that is what it is, by renaming the “.scriv” folder in File Explorer (for example, “Original Name-BROKEN.scriv”. Then, restore the most recent backup[1] and use the File ▸ Import ▸ Scrivener Project... menu command to import the broken project into the restored copy.

That should do a pretty good job of recovering what data it can, and you can go about replacing newer copies of things from that imported copy.

Alternatively you could create a new project from “Blank”, and import into that, then open the two projects side by side and drag and drop what you want to keep into the restored copy of the project.

Which to use may depend on the size of the project. If it is a very large project with a lot of research material that hasn’t changed, it might be better to use a blank project so that you’re only copying over the parts that you want, rather than doubling the size of the now main project. Otherwise it’s really down to preference. I’d prefer to have the restored copy in the main project’s binder for a while, as I might not think of everything to restore all at once and it would be most handy to have it all right there, but it can also cause a little confusion as you’ll have two copies of everything for a while—mainly an issue with Project Search and Quick Search.


  1. Refer to §5.2.3, Restoring from Backups for details. ↩︎

1 Like

Thank you very much!

I am not quite sure, yesterday I did exactly that, but with a new project, it did not work, I guess the issue would be / was imported as well, if I remember right, the same message occurred as when I try to open it directly:

Can one drag from the folder structure of the project that cannot be opened the main folder / the entire project into the GUI of the back up project?

You mean the folder structure of one or both of them in a file manager (as the project to be reconstructed does not open anymore)? But wouldn’t / mightn’t that cause inconsistencies in the back up?

Project size 3,7 GB.

I want everything, restore the entire project as it is / was.

I am not quite sure to understand, but I guess that (a folder containing the imported / copied project) would not be useful, respectively impossible to use, I could not manually check / compare the entire structure in Scrivener, each doc / folder, much too much elements there. If there would be (but I assume, there is none) an option to compare the contents of the folders, it would be good (liker there is between the folder structures of these projects outside of Scrivener). Or what do you mean by “as I might not think of everything to restore all at once and it would be most handy to have it all right there”.? And I guess, Scrivener could not properly handle 7,4 GB big projects according to his general behavior (as it seems to be here, alone by overloading the RAM).

Can one drag and drop single folders / files from the folder structure (in a file manager) of the project to restore to the back up opened in Scrivener?

Okay, well the “Import Project” command is meant to be more “robust” in the sense that if what it is given isn’t a valid project, but looks like the remnants of one, it will just do its best. So often it can be used to restore things mostly the way they were, but depending on the damage it might be even that doesn’t work.

Worst case, there is the fact that Scrivener’s projects are standard files for this very reason (among other reasons too), you can just import the “Data/Files” subfolder as normal files, drag and drop from Explorer. It will be a bit of a tangle since the binder names won’t be used, the internal IDs will be used instead, but at least the words will be there.

If you want a “key” to all of these internal IDs, you could locate the “search.indexes” file in the Data subfolder, copy that somewhere temporary and rename it to “Old Binder IDs.txt”, then import that into Scrivener. You can then search for binder titles, and relatively simply see which ID matches it.

If the search index is broken or incomplete, then the .scrivx also has all of these pairings. I suggest trying the search index first because it is more human-friendly, but the .scrivx isn’t difficult to read either, it just has more information clutter in it. Either way don’t try to import those files directly, copy them and rename them to .txt extension so they are “inert”.

You mean the folder structure of one or both of them in a file manager (as the project to be reconstructed does not open anymore)? But wouldn’t / mightn’t that cause inconsistencies in the back up?

Not quite, for that approach I was recommending dragging and dropping between open binders. The file system wouldn’t be involved in that equation. But if you can’t import the project at all anyway, it’s rather academic.

And I guess, Scrivener could not properly handle 7,4 GB big projects according to his general behavior (as it seems to be here, alone by overloading the RAM).

It really depends on the usage pattern. Scrivener isn’t going to load all of your project at once into memory under normal usage, but I suppose one could get to that point on purpose—say if all ~4GB are RAW photos dropped into RTF files in the Draft folder, and you select the Draft and view as Scrivenings mode. That will necessarily load everything, and probably crash anything but a pretty powerful computer. I don’t know, I’ve never tried it.

Normally though, it only loads what you click on, and normally if someone has gigabytes in their project it isn’t in the Draft but in hundreds of PDF files, videos or whatever else was imported as research—stuff you can’t bulk load accidentally.

1 Like

Maybe there is no damage here at all, the project just does not open anymore.

So there is some random name Scrivener gives each copied / imported doc / folder that the user cannot assign to its content? Whats sense did that make? Why?

So I would copy a file to the open Scrivener, then enter the ID in the search, then find the ID with the titel and then manually rename the file / doc? Repeatedly for each item?

[QUOTE]

You mean the folder structure of one or both of them in a file manager (as the project to be reconstructed does not open anymore)? But wouldn’t / mightn’t that cause inconsistencies in the back up?

Not quite, for that approach I was recommending dragging and dropping between open binders. [/QUOTE]
Very sorry, I do not understand, don’t know what I am missing. To make sure, so the original project cannot be opened. So I cannot see it in Scrivener, I cannot use it in Scrivener, I cannot open it with Scrivener. If I could open it, everything would be very great, I didn’t need to do any restore. So this original project I only can “access” restricted in the folder structure. It is not possible here to open / use it.

Sorry, I am not quite sure what this means now, respectively above all for the method to restore.

Sorry for my confusion and asking again, guess, I missed the answer somehow, what method now is the best to recover the project? And: Can one drag and drop single folders / files or a bunch or even more from the folder structure (in a file manager) of the project that cannot be opened to restore to the back up opened in Scrivener? Without causing inconsistency?

Okey, but as it overloads the RAM here that other programs and the system crash I rather would not rely on that here. So then it seems something here is not normal at all. I have a really trashy Lenovo Notepad here with 14 GB RAM, that commonly can be used.

Thank you very much for your great help!

In your filing systems, ProjectName.scriv\Files\Data has potentially thousands of folders with names comprising 8-4-4-4-12 unique character/number combinations. Each of those folders, in turn, contains a contents.rtf file, essentially with one of your Scrivener folder’s or document’s content.
Scrivener’s ProjectName.scrivx file uses the 8-4-4-4-12 unique character/number combination names to keep track of your work (each contents.rtf file) within Scrivener (instead of natural language names you might have assigned to a folders/documents) and some ancillary stuff like styles. It’s for the Scrivener app’s use, not meant to be interfered with or accessed under normal circumstances.

Maybe a second voice will help.

In Windows, Scrivener sets up a top-level folder with the name of the project and gives the folder the .scriv extension. In my case, this was

Inside that folder is the “test” Scrivner Project file, along with fout folders: Files, QuickLook,Settings, and Snapshots.

Your written words will be in the Files folder, inside of a subfolder called Data, and further into subfolders that have long random names.

What you want to import is the Files folder itself.

Hope this helps demystify @AmberV instructions.

2 Likes

Yes, I understand, sounds very plausible, many thanks. I am wondering why Scrivener not uses the names (or / and at least a part of each name) the user gave the folders / files, maybe additionally to (a part of) its numbering system, as it seems as if quite a few users encounter not normal circumstances. Or - for whatever reason - want to copy files / folders directly from the folder structure (if that is possible at all without causing inconsistencies, but I assume it is).

Actually it seems as if it would be enough to copy some changed / added folders and files since that back up is done to the back up (the new original project) and maybe delete files and folders in the back up being deleted in the old project. To manually compare ALL of the copied files, folders within the back up would just not be possible, I guess.

Yes, thank you for demystifying.

Aside from the odd eidetic out there, what would a name like 135642FH-9967-5622-8239-8989-HTDV45G9HH8P mean to a user? It means everything to a computer and an application’s indexing capability but is gibberish to users.

I assume the Scrivener app creates the name using some form of algorithm and given its length ensure its unique.

1 Like

These are "UUID"s, they are easy to create as just about every programming language has a method to make them. I even have a little one-liner in my text expansion utility that makes them, I just type in $uuid and get “CB6CF68E-BCBF-405B-A86F-7B7A62977EB4” (different every time).

Computer systems use unique IDs for many good reasons. You’re using them right now on this forum, your account has an ID too, the way we see it with the name you typed in to identify yourself is just your “binder name”. Every email you’ve ever received or sent has one. Unique IDs make the digital world go around.

Having to recover your project from IDs is extremely unusual, and I only brought it up as a fall back in case nothing else works. You have that at the very least, but typically there are better ways to recover data.

At any rate, as you speculate yourself, the problem seems to be less of a matter of corruption, and maybe more a bug or overload of some kind. 4GB wouldn’t ordinarily burn through your entire laptop—like I say Scrivener doesn’t even load all of that at once under most circumstances. So something odd is going on with your project, maybe a bad piece of data got imported, that is causing a runaway loop or something. Importing it is just going to cause it to happen again.

2 Likes

Okey, the UUID system, a standard, just does not allow / work with other signs / additions / names (outsied of the system) than the ones generated by the system.

What method now is the best to recover the project? And: can one drag and drop single folders / files or a bunch or even more from the folder structure (in a file manager, e.g. Win Explorer, outside of Scrivener’s GUI) of the project that cannot be opened to the back up opened in Scrivener (GUI)? Without causing inconsistency?

A lot of words in this thread. Why not recover simply from the automatic backups using the procedure described in the Scrivener manual? Messing with the internals of the project should not be required, IMHO.

2 Likes

Where is the “Edit” option here?

Okey, the UUID system, a standard, just does not allow / work with other signs / additions / names (outsied of the system) than the ones generated by the system.

What method now is the best to recover the project? And: can one drag and drop single folders / files or a bunch or even more from the folder structure (in a file manager, e.g. Win Explorer, outside of Scrivener’s GUI) of the project that cannot be opened to the back up opened in Scrivener (GUI)? Without causing inconsistency?

Actually it seems as if it would be enough (and maybe useful to avoid transferring the issue or making it easier to identify the (copied) file having the) issue to copy (only) the changed / added (new) folders and files since that back up is done to the back up (the new original project) and maybe delete files and folders in the back up being deleted in the old project. To manually compare ALL of the copied files, folders within the back up would just not be possible, I guess.

Yes, absolutely, so many words here and even much more letters.

Actually that is what I want to do (I guess, not quite sure what the described method is). But that is not enough unfortunately.

Those content.rtf I referred to are your individual folders and document. Since you can’t open your backups in Scrivener, for whatever reason, open the contents.rtf files one by one with a word processor like Word. And work through each document before Importing it to a new project in Scrivener.
These may be reasons why your project is so large: Do you include pictures and imported PDFs and webpages (as pictures) in your documents? Is your project in one endless document or did you divide your work into smaller sized documents?
14GB of RAM is more than enough to open a project, even one 3.7GB in size.
What changed from the last time you used Scrivener to the time you ran into Scrivener failing to load problems?
You could always take your project to another computer, download the Scrivener app (fully functioning trial for 30 non-consecutive days) onto it and run your project there to see if it’s your project or your machine malfunctioning.

3 Likes

Many thanks!

Manually, yes, and manually try to reconstruct the structure, snapshots, notes, etc. as good as possible in this manner. Yes, that’s the point (I really would like to avoid), an incredible amount of work and time reconstructing each item manually. At least a slight kind of automation would be great.

Maybe better first importing / copying all or a part of the changed / added items, then manually go on restoring. One by one. Is there anything against this approach?

Sorry, I can, but I can’t open the original (that is the problem), the project to be recovered. So I can open the back up and see it in Scrivener, its GUI.

Yes, I do. No webpages as pictures, in other states, I guess.

Small(er) sized ones.

In what regard? I like usual wrote / edited / added stuff. Nothing unusual, I would say. Absolutely no idea what action / information might have caused the issue. If at all.

Yes, thank you, the same issue there. scrivener.exe then just disappears from the Task Manager after a while (like it sometimes does on my Trash-Lenovo).

Alright—your original query was: What is the best way to reconstruct / recover / restore a project that does not open anymore with a back up?
Be that as it may, basically, IF you’re following a backup on close routine set in File > Options > Backup, then your latest backup is a backup of your work in progress. There’s no difference in content, except the backup might be zipped—dependent on your choice.
In that case drag the content the scriv folder out of the zip to Downloads.
When done, rename the ProjectName.scriv folder to ProjectName—OLD.scriv.
Access the .scriv folder.
The project ProjectName.scrivx file will have the old name still.
Double clicking on it will open the project, renaming the scrivx file and the project to ProjectName—OLD.

The question is simple. How much changes have you done to your project since your last backup that were not backed up?
If you have not being doing regular backups, then the only advice is to use the manual process.
If you run your computer and work on your project for days on end, you will not get backups—that’s a major downside to this practice. You will get autosaves from the project in memory, but those would overwrite one another from memory to the files on SSD or HDD.

3 Likes

Oh, yes, absolutely, that is exactly what I wrote, there’s not the slightest doubt—how could anyone even think otherwise? It remains perfectly readable, can be easily proven at any time, and I seriously doubt anyone would be bold enough to deny it. But maybe after all, who knows?

Yes, if I understand correctly, that’s the way I’d like to try it, thank you.

The last working backup (without the issue) is from about two weeks ago or even longer.

Yes, and preferably in a way that the issue is not transferred. I am wondering, can one drag and drop single folders / files or a bunch or even more from the folder structure (in a file manager, e.g. Win Explorer, outside of Scrivener’s GUI) of the project that cannot be opened to the back up opened in Scrivener (GUI)? Without causing inconsistency? And how to find elements deleted in the original so they can be deleted in the backup. How could one do it?

On another thread you mentioned that problems started to happen “after the update”. Was that the update to 3.1.6?

If so, do you have the option to install the version that worked for you on another system and try opening your project?

This may be a long shot, but trying to isolate things here.

For two main reasons. First, the UUID is unique, while the user can accidentally or deliberately give multiple documents the same name. That’s especially important when combining projects. Second, the Binder name of the document can be very long, can include chararacters that are not allowed in file names, and so on.

2 Likes