Restoring a large Yunohost backup fails because not enough space on disk ... but that's not true

What type of hardware are you using: VPS bought online
What YunoHost version are you running: 12.1.15.1
How are you able to access your server: The webadmin
SSH

Describe your issue

So my productive server recently crashed. I have a somewhat recent backup of the entire yunohost instance which was created using the CLI via SSH, backing up everything from user settings to apps to databases to about 420GBs of Nextcloud data.

That backup.tar of about 460GB was written to a remote storage mounted to the old server - in this case, a Hetzner Storage Box.

So I did what I thought was the logical choice: I spun up a new server, remote-mounted the storage box into /home/yunohost.back/archives/Hetzner in order to circumvent possible “wrong location” hiccups and started the restore process using the CLI.

Two hours later the process failed due to “not enough space”.

I then symlinked the .tar from the remote drive to /home/yunohost.backups/ and started the process again.

Two hours later, it failed due to “not enough space”.

However, in the meantime, about 155GB have been written to /dev/vda1, leaving about 592GB available on that disk.

So, in theory, this means

  1. there’s de facto enoug space
  2. the process starts, but then interrupts itself at some point, writing data to disk until then
  3. I need to figure out another way of doing this.

Is it possible to only partially restore a full_system_backup.tar? This would enable me to go app by app, thereby hopefully circumventing whatever weird troubles the restore process encounters. How would I go about that?

NB: I could also start the restore process from the webadmin … but ever since I put the symlink to the remote Hetzner backup.tar in the yunohost.backups folder, the webadmin backup function just loads and loads and loads forever, never actually displaying any files or anything at all really.

Edited to add:

sudo yunohost backup restore /home/yunohost.backup/archives/hetzner_mount/backups/20250812-153523.tar --apps linkwarden --debug

returns

35   DEBUG   acquiring lock...
45   DEBUG   lock has been acquired
82   DEBUG   loading python module yunohost.backup took 0.037s
82   DEBUG   processing action 'yunohost.backup.restore'
83   INFO    Preparing archive for restoration…
84   DEBUG   action executed in 0.001s
84   DEBUG   lock has been released
Traceback (most recent call last):
  File "/usr/bin/yunohost", line 108, in <module>
    main()
  File "/usr/bin/yunohost", line 97, in main
    yunohost.cli(
  File "/usr/lib/python3/dist-packages/yunohost/__init__.py", line 59, in cli
    ret = moulinette.cli(
          ^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/__init__.py", line 143, in cli
    ).run(args, output_as=output_as, timeout=timeout)
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/cli.py", line 530, in run
    ret = self.actionsmap.process(args, timeout=timeout)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 580, in process
    return func(**arguments)
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 2265, in backup_restore
    restore_manager.mount()
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 1115, in mount
    mkdir(self.work_dir, parents=True)
  File "/usr/lib/python3/dist-packages/yunohost/utils/file_utils.py", line 280, in mkdir
    raise Exception(f"Folder {path} already exists")
Exception: Folder /home/yunohost.backup/archives/hetzner_mount/backups/20250812-153523.tar already exists
timon@gedoens:~$ 

I don’t know what that means. Of course the folder already exists?!

Share relevant logs or error messages

from this discussion [SOLVED] BACKUP / RESTORE : How to restore a (too) huge backup? as I forgot to actually save the snippet before I terminated the screen session I used to execute the restore command

Progress after rebooting

So I don’t know if that’s what did it, but I rebooted the system after the webadmin crashed while trying to look at the remote-mounted symlinked backup.tar.

Now I’m getting this:

~$ sudo yunohost backup restore /home/yunohost.backup/archives/20250812-153523.tar --debug

28   DEBUG   acquiring lock...
36   DEBUG   lock has been acquired
71   DEBUG   loading python module yunohost.backup took 0.035s
71   DEBUG   processing action 'yunohost.backup.restore'
73   WARNING YunoHost is already installed
196  DEBUG   Using selector: EpollSelector

Do you really want to restore an already installed system? [y/N]: y

16618 INFO    Preparing archive for restoration…
16618 DEBUG   action executed in 16.547s
16619 DEBUG   lock has been released
Traceback (most recent call last):
  File "/usr/bin/yunohost", line 108, in <module>
    main()
  File "/usr/bin/yunohost", line 97, in main
    yunohost.cli(
  File "/usr/lib/python3/dist-packages/yunohost/__init__.py", line 59, in cli
    ret = moulinette.cli(
          ^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/__init__.py", line 143, in cli
    ).run(args, output_as=output_as, timeout=timeout)
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/cli.py", line 530, in run
    ret = self.actionsmap.process(args, timeout=timeout)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 580, in process
    return func(**arguments)
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 2265, in backup_restore
    restore_manager.mount()
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 1115, in mount
    mkdir(self.work_dir, parents=True)
  File "/usr/lib/python3/dist-packages/yunohost/utils/file_utils.py", line 280, in mkdir
    raise Exception(f"Folder {path} already exists")
Exception: Folder /home/yunohost.backup/archives/20250812-153523.tar already exists

Sooo this seems to be catch-22: in order to fully restore a full system backup, the process would ideally like to start on a fresh-fresh, clean ynh install, ideally before all of the postinstall magic.

On the other hand, I cannot restore a full system backup without putting all of the domains in place that the backup requires, which means I must do the postinstall procedures, correct?

Sooo uuuh… how does anyone ever restore a ynh backup?

No, a full backup contains everything, users, domains, permissions, api keys, etc…

So to avoid misunderstandings here: according to the official doc, you need to manually configure the domains used by your old machine on the new machine before restoring the backup:

To restore an app, the domain on which it was installed should already be configured (or you need to restore the corresponding system configuration). You also cannot restore an app which is already installed… which means that to restore an old version of an app, you must first uninstall it.

(see here)

So I thought that’s what I’m doing: spin up a new machine, do the post-install as minimally as possible (set up main user with admin and ssh privileges, set up “old” domains and subdomains) and then do the backup-restore.

If you need to move an app from one server to another. But in your case, you have a full backup, which contains everything. And you don’t need to run the post install, just install yunohost and directly run the restore

oh damn, thank you - I was so focused on setting the domains back up because last time I did this, I went app by app.

I’l see if there’s a way to completely reset/purge the yunohost install and try again or possibly nuke the server, do the install but not the post-install and then try again.

Edited to add:

There’s no way to completely remove a yunohost instance once it’s been installed, so back to the drawing board according to Best way to uninstall YunoHost so I can reinstall it?

So for anyone finding themselves in a similar situation: don’t do what I did. Instead: spin up a fresh install but don’t go through post, mount your remote drive and see if that works.

Unfortunately, I’m still stumped by the backup restore process.

sudo yunohost backup restore /path/to/remote/drive/backup.tar --debug

returns

24   DEBUG   acquiring lock...
30   DEBUG   lock has been acquired
57   DEBUG   loading python module yunohost.backup took 0.027s
57   DEBUG   processing action 'yunohost.backup.restore'
8438487 DEBUG   action executed in 8438.430s
8438487 DEBUG   lock has been released
8438487 ERROR   Not enough space (space: 276137304064 B, needed space: 493442703977 B, security margin: 104857600 B)

Do you have any idea how to solve this? I’m working from a fresh server with ynh installed but not post-installed like you suggested, but I still can’t restore my backup even though I have 750GB of available disk space for a 460GB backup. I don’t understand what’s happening. Is there a way to force the restore process?

It will require the double of that space, one for unpacking and the other for restoring.

Anyway, try restoring system only --system.
If you have the possibility of compressing your backup, that may help

I kinda seem to be back to square one: the process fails because the backup already exists. Which has me confused, because yeah, it exists because you’re supposed to restore that backup?!

I tried the --system restore pointing directly to the .tar on the remote-mounted drive. That failed because the process said the file already exists.

I symlinked that remote-mounted .tar to yunohost’s backup folder, but still the process fails because the file already exists.

I might try to mount the remote backup into a completely different location, but something tells me that’ll fail again as well. I’m just stumped.

root@ynh:/home/# yunohost backup restore /home/yunohost.backup/archives/20250812-153523.tar --debug --system

27   DEBUG   acquiring lock...
33   DEBUG   lock has been acquired
63   DEBUG   loading python module yunohost.backup took 0.030s
63   DEBUG   processing action 'yunohost.backup.restore'

9692943 INFO    Preparing archive for restoration…
9695751 DEBUG   action executed in 9695.687s
9695751 DEBUG   lock has been released

Traceback (most recent call last):
  File "/usr/bin/yunohost", line 108, in <module>
    main()
  File "/usr/bin/yunohost", line 97, in main
    yunohost.cli(
  File "/usr/lib/python3/dist-packages/yunohost/__init__.py", line 59, in cli
    ret = moulinette.cli(
          ^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/__init__.py", line 143, in cli
    ).run(args, output_as=output_as, timeout=timeout)
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/cli.py", line 530, in run
    ret = self.actionsmap.process(args, timeout=timeout)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 580, in process
    return func(**arguments)
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 2265, in backup_restore
    restore_manager.mount()
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 1115, in mount
    mkdir(self.work_dir, parents=True)
  File "/usr/lib/python3/dist-packages/yunohost/utils/file_utils.py", line 280, in mkdir
    raise Exception(f"Folder {path} already exists")

Exception: Folder /home/yunohost.backup/archives/20250812-153523.tar already exists

use yunohost backup restore 20250812-153523.tar --debug --system

otherwise the command tries to copy the file to itself, as it is in the yunohost.backup/archives directory

Thanks! I noticed that during the unsuccessful restore attempts, yunohost had written a bunch of stuff into /home/yunohost.backup/archives, so I went ahead and rm -rfed that entire directory. I then symlinked the backup 20250812.tar to yunohost’s backup/archives folder and executed that command like you suggested.

Now I’m getting somewhere:

root@ynh:/home/# yunohost backup restore 20250812-153523.tar --debug --system
49   DEBUG   acquiring lock...
58   DEBUG   lock has been acquired
108  DEBUG   loading python module yunohost.backup took 0.050s
108  DEBUG   processing action 'yunohost.backup.restore'
9750078 INFO    Preparing archive for restoration…
9750080 DEBUG   Extracting needed files from the archive…

This is looking better than before!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.