Backup: Not enough memory on the memory card.
Hi,
I've been trying to create a backup of my files before upgrading to 3.2.0 (now on 3.1.0.11). But it keeps failing with the message "Not enough memory on the memory card.". I've just bought a new 32 GB micro SD card and Storage in Settings show 10.3 GB user data, so it should fit.
The logs says
... ./Gallery/blobs/Videos/Camera/20180921_175546.mp4 ./Gallery/blobs/Videos/Camera/20180817_115007.mp4 ./Gallery/blobs/Videos/Camera/20160715_010.mp4
Standard error was: tar: /run/media/nemo/3564-3038/sailfish_backup_2019-11-08T17-28-45Z.tar: Wrote only 4095 of 10240 bytes tar: Error is not recoverable: exiting now
[ERROR] 2 No disk space remaining. Status = Finalizing [UI] Finalising operation Status = Finished Deleting /run/media/nemo/3564-3038/sailfish_backup_2019-11-08T17-28-45Z.tar following failed backup/compress operation Removing working files in /home/nemo/.local/share/system/privileged/Backups-tmp/units/sailfish_backup_2019-11-08T17-28-45Z
The Phone is an Xperia XA2 Ultra Dual SIM.
Best regards,
Jasper
Is this fat32 issue?
coderus ( 2019-11-08 23:52:04 +0200 )editYou should move manually all photos/videos on the sd card (and make an extetnal backup also), the Sailfish backup will then be super fast and way smaller.
Sthocs ( 2019-11-09 00:14:38 +0200 )editProbably same reason as here: https://together.jolla.com/question/216239/backup-should-handle-no-space-left-on-device/ ?
Device storage full?
peterleinchen ( 2019-11-09 02:49:02 +0200 )editI have just experienced the same problem, and I believe it is caused by the maximum filesize on FAT volumes. I reformatted my SDcard to use the ext4 filesystem without journalling, and after rebooting, reran the backup to get a file size of the backup tar of 4335974400 bytes, which is larger than the filesize limit on vfat of 4294967295 bytes. The average phone user will not be able to do this, and in any case probably would not want to, as ext4 is not ideal for portability across operating systems.
I suggest that Jolla could usefully modify the backup script to pipe the output of tar to the 'split' program
tar <whatever> | split --bytes=4294967295 - backup.tar.gz. (the trailing dot is signficant) This will produce files backup.tar.gz.aa backup.tar.gz.ab backup.tar.gz.ac</whatever>
and so on.
A restoration script simply can use cat to feed the files back into tar
cat backup.tar.gx.* | tar <blah blah=""></blah>
(There are probably better ways, this stack exchange item gives some ideas and links: https://unix.stackexchange.com/questions/61774/create-a-tar-archive-split-into-blocks-of-a-maximum-size )
Ratiodunk ( 2020-01-22 14:40:04 +0200 )editJust to add to my above comment - the problem would also be 'solved' if sdcards could use F2FS, However, I believe Jolla would be best served by modifying the backup software to split overlarge backups into files that can be stored on FAT volumes so that the user-experience for non-technical users is made as good as possible. Like it or not, fat file systems are the common denominator for exchanging data on removeable rewriteable physical devices. Unless and until some of the more popular operating systems support F2FS (or even UDF) well, Jolla need to make sure that users can remove the SD card and it is readable on other systems: which means using vFAT, and splitting over-large backups.
Ratiodunk ( 2020-01-22 23:58:46 +0200 )edit