DISCLAIMER: Everything below is highly experimental. If you want to do something similar, feel free to do so at you own risk. Use your own brain to adapt commands to your own situation. If you do this with important data – always backup first. Ideally in multiple places.
ATTENTION: Face recognition data is apparently not recovered with this procedure. You will probably have your albums back though. This article will not help you if you already moved and migrated your disks.
According to Synology’s KB article the migration of disks between different DiskStation models depends on the respective CPU architecture of the device.
In my case I wanted to migrate from A DS416slim to my new DS920+. The DS416slim had become slow for Photos usage after DSM7 upgrade (someone will comment „you better read the release notes blah blah…“), but I wanted to keep the disks for the time being and make another investment later.
Unfortunately the the two devices are listed in Group 1 and Group 3 of Synology’s compatibility table and with regards to the migrations it states „Re-configuring package settings is required after migration. Original package data and tasks are lost.“
Unlike the performance implications of a DSM7 upgrade on slow devices I looked up this limited compatibility *beforehand* – so I expected that there would be problems to preserve my photo albums and face recognition data and made my mind how I could work around it.
As a safety measure a made a HyperBackup onto my other DS920+ which luckily had a good amount of space left. It took over 2 days to complete. Fantastic. Not. But better be safe than sorry!
In addition to that I dumped the synofoto postgres database onto my /photo share. That’s how it is done (of course there are other – and better – ways too…)
SSH into the DiskStation that you want to migrate and then use pg_dump to make a dump of the synofoto database. In my case the „photo“ share sits on volume1. You can of course back up to any location you prefer.
sudo pg_dump -U postgres synofoto > /volume1/photo/synofoto-backup-2022-09-19.sql
This process took a bit of time. In my case it produced a dump file of around 4GB. This is because the synofoto database contains all the thumbnail images. My photo collection is around 1Tb, so if your collection is different size, the database can also be bigger or smaller.
After the database dump had completed I shut down the DS416slim and moved the diskst into the DS920+
The migration wizard indicated that migration was possible (I could select it) but when the DiskStation came back it indicated errors on various packages and started automatically to resolve these errors by repairing the packages. It’s useful to watch the logs while this is happening so that you don’t try anything at the same time and don’t interfere with what the system is trying by itself.
After all repairs completed (seemingly successful) it turned out, that my Photos app was blank and started up as after a new install. All albums etc. were gone. So even though I had some hopes in between that it would „just work“ the result was like described in the article: „Re-configuring package settings is required after migration. Original package data and tasks are lost.“
So I gave it a try to see if restoring the postgres database is actually all it needs to have everything as before.
Steps I took:
- Shut down Photos from Package Manager
- Figure out how restoring works with Postgres.
So it seems that it wasn’t ideal, that I took the dump without any parameters. by default pg_dump saves a plain text file. One might think that’s fine, but there’s one caveat. Plain text dumps can not be recovered with pg_restore – they need to be recovered with psql. Why is that a problem? While pg_restore supports a parameter –clean which basically truncates (or drops?) the respective tables and when you restore you really have exactly what was on your source system – psql seems to just add what you have in your dumpfile to whatever exists in the tables already. The result was lots and lots of foreign key contraints and duplicate record errors. Not ideal. So I figured out what I could do. I could not make a new dump though – I had to work with what I had.
So I emptied the current synofoto database on the target system before trying to restore another time.
sudo psql -U postgres -d synofoto
Make sure that your command line shows synofoto (indicates, that you’re on the right db). The following should leave you with a blank synofoto db. It’s the first option, taken from here
-- Recreate the schema
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
-- Restore default permissions
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO public;Leave psql with \q
Then you can restore the dump with less issues.
sudo psql -U postgres -d synofoto < /volume1/photo/synofoto-backup-2022-09-19.sql
After it completed I went back to Package Manager to re-enable Photos.
Entering the Photos app it seemed that everything was back. Hurray!
On second glance though it seems that face-recognition results are not preserved or need re-indexing.
I will update here what I encounter…
