nextbackup
nextbackup copied to clipboard
restoring all tables fails
I never managed to restore a backup made with ownbackup. No matter which ownCloud/NextCloud version I use I get an error. The screenshot attached was generated using NextCloud 12.0.3. Was the error that I selected all tables at once?
Regards, nieroster
The internal API of oC/NC is used for creating the data structure... I can't really say much about this message. Did you maybe run into #14?
Sorry not get back sooner on this....
Yes, this looks exactly like my error. Does it depend on the OC/NC version? How can it be fixed?
Regards, nieroster
It's a known bug that oC and NC are not keen to fix (my report got closed back then). The thing I did back then is documented in #14.
Thanks for your quick reply!
I'm not quite sure how to get this working. Shall I submit a bug report to the NextCloud team? Or can you please clarify the issue with them? In the current situation OwnBackup is not very helpful when data needs to be restored.
Regards, nieroster
You could start to take a look at the backup dump if the column that seems to be missing is really missing. Your error message doesn't look very familiar to me...
Shall I submit a bug report to the NextCloud team?
I'm not sure if they could help you if you only show them a sql error message that may or maynot be cause by some private api of NC...
Long time since this was opened in first place :)
I think I have found something about it: I have the same problem in a Nextcloud 19.0.9 setup here, and when I try a full restoration of the backup from NextBackup I hit exactly the same error with oc_calendarobjects table. Checking about the table structure created when you try to restore with NextBackup I have found that the file "structure.xml" that belongs to each of the backups created by NextBackup, does not have defined the "calendardata" field on it. I have tried to manually creating it, and it seems to work great!
I have a doubt though, I don't know how to set the field type of this field particularly (MySQL dumps define it as longblob), but I have realized that there are 3 more longblob fields in the MySQL dump (oc_cards, oc_recent_contact and oc_schedulingobjects), and comparing each of them with your equivalent structure.xml, I have seen that you just set it with a name and that's all, is that ok for a blob type?.
I guess https://github.com/pbek/nextbackup/issues/14#issuecomment-286201871 is still an issue...
But calendardata is not in structure.xml at all, that's why oc_calendarobjects complains during restoration. "blob" thing definitively belongs to #14 :)
I think this issue should be marked as a bug, don' you?
Do you have logs from your server? The internal (private and now deprecated) NC api is used to determine which tables there are and to get their content.