Upgrading Fedora release of a Droplet

Posted March 18, 2020 1k views

I have multiple droplets running an old version (F27) of Fedora. For my non-cloud (e.g., my own laptop and home servers) systems, I just run through the upgrade-in-place mechanism (fedup-that-was) after making a backup – in part because the package updates do any migration/relocation/modification to their own data.

A lot of people say ‘create a new droplet with the new FC release and then move everything over.’ After decades in the field, I am very reluctant to follow that path, in part because

  • data format migration is then up to me, not the package upgrade, and
  • there’s an excellent chance I’ll miss something from all the various locations (e.g., /{etc,var,opt}/**/*).

Is there any reason not to use dnf system-upgrade on a droplet?


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hello, @GenghisKen

Hope you’re well!

  • The migration option to move your data to a new server/droplet is considered a lot more safe as you can test if your site/application is properly working from the new environment (you can fully test everything before “pushing” your site live from the new server). Also this process is not really complex as you can move the site/application files and database using many tools like FTP/sFTP. rsync, scp to the new server and then just configure the rest of the server configurationlike web server, database engine and so on.

You do not need to copy all the files from /etc /var /opt

You can simply deploy the new droplet and then migrate the content of your site/application and test if everything is working as expected.

  • Where on the other side if you go and try to upgrade the OS a lot of things can go wrong and you might end up losing your data and break the server configuration. You can of course take a backup of your files download it locally and also create a snapshot of the droplet and then go ahead and try to upgrade the OS.

Note: You need to take a full backup of your files and databases before going with any of the two options. You can then copy the backup locally on your machine in order to make sure you have the backup available in case something goes wrong and you can’t connect to the server.
It is really important to have a working copy of the server config files as well in case you have a custom setup of the web server or of the database engine as well. You can do a quick copy of the most important files and save them locally as well, as you might need them when you tweak the configuration on the new server.

Hope this helps!


  • That’s just it – my server is used for development as well as containing auto-deployed elements. So I don’t know what-all has been added/modified by hand as opposed to being auto-landed by Puppet/Ansible, etc.

    How about this:

    1. Create a backup.
    2. Create a snapshot.
    3. Spin the original instance down.
    4. Spin up a new instance from the snapshot.
    5. Upgrade the new instance with the OS upgrade mechanism.
    6. If the upgrade appears copacetic, delete the spun-down original instance. Does that sound feasible?

    Yes, I know I need to get everything under config control – of course, this server happens to be my Puppet server..

    • Hello, @GenghisKen

      If the server is or development as well as containing auto-deployed elements it’s important to have a backup and snapshot for the droplet in case something goes wrong.

      The steps you’ve mentioned sound like a plan and you will have the chance to test if everything is working fine on the new droplet configured from the snapshot you’ve taken.

      Let me know how it goes.