Archived files don't stay on sd card after removing it

Hello, I’m new to Linux and I was trying a little bit of bash scripting. I wanted to archive and compress files in my home folder and put them onto an sd card, but I ran into two problems:

  1. It takes way too long to perform this task

real 2m32,114s
user 0m0,563s
sys 0m0,125s

This is one of the shortest times I got, usually it’s more like 4-5 minutes

  1. When I remove the sd card I’m putting the files on and then mount it back, I can’t see my backup.gz file. There’s only a folder backup, which has backup.tar inside. I can’t access this backup.tar, though. In GUI I get this error

Loading the archive ‘/run/media/user/340C-1CEB/backup/backup.tar’ failed with the following error:
No suitable plugin found. Ark does not seem to support this file type.

This is the script I am using. I know there’s probably an easier way to do this, but as I said, I’m only a beginner. There probably won’t be any good use for this script, I just wanted to try it out.

#!/bin/bash
if [ -d “/run/media/user/340C-1CEB” ];then
cd /run/media/user/340C-1CEB
rm -r backup.gz
mkdir backup
cd /home/user
cp -r Documents Downloads scripts /run/media/user/340C-1CEB/backup
cd /run/media/user/340C-1CEB
tar -czf backup.gz backup && rm -r backup
else
exit
fi
exit

Other than this, I also tried archiving my directories directly to my sd card, but that took even longer (15-30 minutes). That is why I’m now first copying them and then archiving them.

I would like to know why this process takes such a long time and why the files don’t stay on my sd card after I remove it.

Thanks to anyone who answers!!

In reply to your first question, it could be a matter of any of the following, or any combination thereof… :arrow_down:

  • the speed of the SD card
  • the speed of the bus that the SD card is connected to
  • the amount of available RAM versus the total size of the files being copied

In reply to your second question, first of all, there is a syntax error in your script, namely in the cp command. You are not telling cp which of the three directories on its command line are the source and which is the destination, and you’re also missing the trailing slash on the destination directory ─ see… :arrow_down:

man cp

… for details. Note the -t option. :wink:

Your script is also inefficient. For instance, you are trying to copy all the files to the SD card, then archive and compress them with the SD card as both the source medium and destination medium ─ please also note that SD cards do not support TRIM and that such an operation therefore creates write amplification ─ which is bound to be slow. You would be much better off using /tmp for the copying, archiving and compressing, because /tmp is a tmpfs, i.e. a virtual-memory-based filesystem.

So, allow me to rewrite your script more efficiently and more safely… :wink: :arrow_down:

#!/bin/sh
#
# We will invoke "sh" as the shell, instead of "bash".  In Manjaro, this
# will still invoke GNU Bash, but in a more portable form ─ i.e. in
# strict Bourne Shell mode, so that the script can also be executed on
# machines that have a traditional Bourne Shell and do not have GNU
# Bash installed.

# First, let's see whether we're in our home directory, and if not,
# we'll "cd" into it.

if [ ! "${PWD}" = "/home/user" ]
then
   cd "/home/user"
fi

# Now we test for the existence of a backup directory in /tmp, and
# if it doesn't exist, we'll create it, and then we'll copy the desired
# contents over from our home directory to the backup directory
# by way of a simple loop.

if [ ! -d /tmp/user/backups ]
then
   mkdir -p /tmp/user/backups
   for dir in Documents Downloads scripts
   do
      cp -r /home/user/${dir} /tmp/user/backups/
   done
fi

# Now it's time to create our archive.  Note that we are not creating
# the archive in the same directory as the files it will contain.

tar -czf /tmp/user/backup.tar.gz /tmp/user/backups/*

# Since it is not clear whether you really want to do things this way, 
# I am following your logic of deleting a pre-existing archive file
# on the SD card and creating a new one, but strictly speaking, this is
# redundant, because a pre-existing archive will either way get
# overwritten by the copy from "/tmp".
#
# Also do note that a "tar" archive can be appended to ─ see the
# "man" page. ;)

if [ -d /run/media/user/340C-1CEB ]
   then 
      if [ -f /run/media/user/340C-1CEB/backup.tar.gz ] 
         rm -f /run/media/user/340C-1CEB/backup.tar.gz
      fi
      cp /tmp/user/backup.tar.gz /run/media/user/340C-1CEB/
   rm -rf /tmp/user/backup*
fi

# That's all, folks! :p

The above script has not been tested, but should work. If you find any errors in its execution, then feel free to let me know and then I’ll fix them. :wink:

The above script could also be improved in efficiency by skipping the step of copying the source files to /tmp, because if the archive on the SD card were to be extracted, then it will now extract the files to /tmp again, instead of to your home directory. However, I will leave that to you as an exercise. :stuck_out_tongue:

1 Like

Your script is great and takes way less time to execute, but my main problem still remains. When I use this script I end up having backup.tar.gz on my sd card:

[user@user-linux 340C-1CEB]$ ls
backup.tar.gz

I am able to see the contents of backup.tar.gz and I can extract it as well.

But after I remove this sd card from my pc and then put it back in the file isn’t the same:

[user@user-linux 340C-1CEB]$ ls
backup

[user@user-linux 340C-1CEB]$ ls backup
backup.tar

[user@user-linux 340C-1CEB]$ tar -tvf backup/backup.tar
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

Trying to access it in a file manager doesn’t work either.

I would like to be able to keep the files on the sd card even after I remove it from the pc, which isn’t happening, for some reason.

First things first: before removing the SD card, you must properly umount it. This ensures that any open files on the card will be properly closed again. Not doing this will result in file corruption and errors.

Secondly, the filename appears to be abridged. The file created is backup.tar.gz, and yet your listing of the files shows backup.tar. This can only mean one thing, namely that the filesystem on the SD card is not a UNIX/POSIX filesystem, and ─ crucially ─ that it doesn’t support long filenames. I’m guessing that it’s a FAT-12 or FAT-16 filesystem, because FAT-32 and NTFS both support long filenames.

Given that SD cards don’t support TRIM, I would advise you to reformat it as ext2. Make sure you make a backup of the card’s contents first before formatting, because reformatting will erase everything that’s on it.

Great, thanks! Reformatting the sd card helped.

1 Like

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