Hm maybe? But how (migrate from VM to YuNO-more VM?!)

Because NextCloud is awesome.
There is not only file access (and a companion app quite usefull), there is also a contact app, calendar, and many many other tools.
But in term of used space, my server is 90% files from NextCloud, all other apps are much more lightly used (even Synapse, heavily used, is mostly text)

1 Like

sure, I tried it myself then it crashed for some unknown reason (look at previous posts) then I abandoned It and now it’s just slowly tearing away.

How is this possible, the SSD has 1 Tb?
Info: Preparing archive for restoration…
Traceback (most recent call last):
File “/usr/bin/yunohost”, line 72, in
parser=parser
File “/usr/lib/moulinette/yunohost/init.py”, line 29, in cli
top_parser=parser
File “/usr/lib/python2.7/dist-packages/moulinette/init.py”, line 120, in cli
args, output_as=output_as, timeout=timeout
File “/usr/lib/python2.7/dist-packages/moulinette/interfaces/cli.py”, line 477, in run
ret = self.actionsmap.process(args, timeout=timeout)
File “/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py”, line 592, in process
return func(**arguments)
File “/usr/lib/moulinette/yunohost/backup.py”, line 2128, in backup_restore
restore_manager.mount()
File “/usr/lib/moulinette/yunohost/backup.py”, line 1024, in mount
self.method.mount()
File “/usr/lib/moulinette/yunohost/backup.py”, line 1908, in mount
tar.extractall(members=subdir_and_files, path=self.work_dir)
File “/usr/lib/python2.7/tarfile.py”, line 2081, in extractall
self.extract(tarinfo, path)
File “/usr/lib/python2.7/tarfile.py”, line 2118, in extract
self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
File “/usr/lib/python2.7/tarfile.py”, line 2194, in _extract_member
self.makefile(tarinfo, targetpath)
File “/usr/lib/python2.7/tarfile.py”, line 2234, in makefile
with bltn_open(targetpath, “wb”) as target:
IOError: [Errno 28] No space left on device: ‘/home/yunohost.backup/tmp/20210315-201810/apps/wordpress__3/backup/var/www/wordpress__3/wp-content/uploads/2020/12/canon-zoemini-mobiele-fotoprinter-10-sheets-wit_5fd7fb1ccf233-100x100.jpeg’
root@ECZ-SRV-01:/home/ecz#

Schermafbeelding 2021-03-19 om 14.01.06
@Aleks or @Mamie

is there maybe a way to host the backup file on a different disk than the installation drive?

On my side, I created a link from /home/yunohost.backup/archives to another disk
Take care to only link this folder, I had problems when I linket all /home/yunohost.backup to somewhere else (there are many optimisations in the backup procedure that do not like links)

I consider that as a yes

@Mamie to be clear, if I drop the backup on let’s say an external drive and mount it to the yuno backup folder im fine right.

I know that it is basic linux stuff but sometimes things are different with yuknow

Now I get this issue?!

root@ECZ-SRV-01:/home/ecz# yunohost backup restore 20210315-201810
Info: Preparing archive for restoration…
20Traceback (most recent call last):
File “/usr/bin/yunohost”, line 72, in
parser=parser
File “/usr/lib/moulinette/yunohost/init.py”, line 29, in cli
top_parser=parser
File “/usr/lib/python2.7/dist-packages/moulinette/init.py”, line 120, in cli
args, output_as=output_as, timeout=timeout
File “/usr/lib/python2.7/dist-packages/moulinette/interfaces/cli.py”, line 477, in run
ret = self.actionsmap.process(args, timeout=timeout)
File “/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py”, line 592, in process
return func(**arguments)
File “/usr/lib/moulinette/yunohost/backup.py”, line 2128, in backup_restore
restore_manager.mount()
File “/usr/lib/moulinette/yunohost/backup.py”, line 1024, in mount
self.method.mount()
File “/usr/lib/moulinette/yunohost/backup.py”, line 1895, in mount
tar.extractall(members=subdir_and_files, path=self.work_dir)
File “/usr/lib/python2.7/tarfile.py”, line 2081, in extractall
self.extract(tarinfo, path)
File “/usr/lib/python2.7/tarfile.py”, line 2118, in extract
self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
File “/usr/lib/python2.7/tarfile.py”, line 2202, in _extract_member
self.makelink(tarinfo, targetpath)
File “/usr/lib/python2.7/tarfile.py”, line 2280, in makelink
os.symlink(tarinfo.linkname, targetpath)
OSError: [Errno 38] Function not implemented
root@ECZ-SRV-01:/home/ecz# 20

@Aleks I tried to install/upgrade python but it’s already the latest version but it did not help. What to do?

@Mamie maybe?

Why the silence? @Aleks you assured me that it should go flawlessly, and now It’s taking too long and this is costing a lot of customers, so please provide a fix or patch it.

Well what can I say, this entire thread is just epicly confusing … at some point you had disk space issue, also I’m still heavily puzzled on how can a backup weight 500 ish GB just for a bunch of wordpress … I mean, if you really are hosting an e-commerce thing with 100 000 product, and similar trade volume, maybe you should not improvise the maintenance of your server …

But anyway:

Naively that sounds like a situation where you’re trying to extract an archive that contain a symlink to a filesystem that doesn’t support symlink …

Could it be that the filesystem is ntfs or something … What does lsblk -f tell ?

1 Like
NAME        FSTYPE LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                  
`-sda1      ntfs   x             CAE08974E0896791                                    
sdb                                                                                  
`-sdb1      ntfs   ECZ_SRV_FS_01 CE78922B78921277                       52.7G    94% /mnt/fs-01
sdc                                                                                  
|-sdc1      vfat                 916A-476E                             505.9M     1% /boot/efi
|-sdc2      ext4                 c6dd4fb5-33cf-4c6d-9f56-6291136ab9a7  829.8G     0% /
`-sdc3      swap                 93f178a6-b4fa-4b7b-9ef7-7680b711325c                [SWAP]
sdd                                                                                  
`-sdd1      exfat  Naamloos      6055-018B                             515.8G    45% /mnt/srv-backup
nvme0n1                                                                              
|-nvme0n1p1 vfat                 8638-1668                                           
|-nvme0n1p2                                                                          
|-nvme0n1p3 ntfs                 82EA3E3BEA3E2BB3                                    
`-nvme0n1p4 ntfs                 78C48029C47FE7B0                                    
ecz@easycomp:~$

Let’s map that out a little better.
The disk is > ssd1 which is formatted with exfat > the drive name is nameless but then in dutch: Naamloos.
UUID: 6055-018B
Size 515.8G in use 45%
it’s mounted to: /mnt/srv-backup which is linked to home/yunohost.backup

so should I try to convert it or reformat it and recopy the backup, or shall I take a rope and hang in there swinging :wink:

Yes :+1:

How about exFat? Since that seems the only one with inter-compatibility between MacOS, Windblows and Linux.

exfat is apparently precisely what was the problem here, because it doesn’t seem to be able to handle symlinks

huh what? Who are you? Who am I? and where am I? My brains… I don’t feel them… giphy-15

First why does yunohost restore backup > Unpacking archive to /tmp/ this to me seems hassle because of that I constantly get the disk is full errors.

However if it did unpack the archive to the final destinations, it should not have given any error.

So in the end, I created a bakup without the megastore. Restored it to the new install. That worked and now I’ve rebooted back in the old installation and created a separate backup which I restored after the main part on to the new install.

Cumber-sum YES. Does it work yeah kinda. can I recommend it NOOOOO