On Mon 17 Feb 2020 at 15:27:06 (+0000), Graham Seaman wrote: > On 17/02/2020 06:30, john doe wrote: > > On 2/16/2020 11:45 PM, Graham Seaman wrote: > > > > > Of course, though this would be easier if I was more sure where > > > everything was. But the data's no use without the software to read it. > > > > > https://docs.gitlab.com/ee/raketasks/backup_restore.html > Thanks - bit embarassing I didn't know that existed (I don't think > there was a backup option when I first installed it). But I've done > pretty much the same, but manually - rsyncing off the data files, > psql_dump, etc. > > Don't Gitlab has some kind of forum/mailing list? > > Yes, it has many forums. I was just hoping someone working on the > debian side might pick up on this - the debian layout seems rather > different from the vanilla one(s), though maybe just because the > version I had was so old. > > > This will not help you for now but the following could be useful in the > > future: > > > > If you have VMs available, I would suggest you to have a clone of your > > production "server" and to first on this VM how the upgrade process goes. > > I hadn't thought of running a VM clone of the server - might be > generally useful. But the server's main jobs are as a router, > firewall, dnsmasq, mail server, which is where the main problems > usually are in upgrades, and I think it would be hard to duplicate the > low-level comms stuff meaningfully in a VM
Would it be possible to run a live stretch system (or install one) on another machine, onto which you copy the files from your server. You should be able to install a version of gitlab old enough to handle your old data. (If necessary, for stretch, read jessie.) You might not know which non-Debian files *are* necessary for gitlab to run but presumably you know which trees of files you *don't* need on this system: anything to do with the "main jobs" you mentioned, for example. Cheers, David.
