In CentOS I have a Web Application Root on which I have a website directory.
I would like to make an immediate backup of that website's directory by using the zip utility. The code works and tested.

Although I already use set -x and zipping is verbose (I'm not sure if due to set -x or zip default behavior), the trace is super long and hard to follow - I cant vertically-scroll all of the way top of it through Putty Window in Windows10 Home.
I fear I don't have enough testing to ensure that the file was created, in what size (to assume the size is plausible) and such (maybe just adding ls -la ${war}/mediawiki_general_backups, is enough):

date="$(date +%F-%T)"
war="$HOME/public_html" # Web Application Root
zip -r "${war}/mediawiki_general_backups/${domain}-directory-backup-${date}.zip" "${war}/${domain}"
  • \$\begingroup\$ Theorizing on reasons/s for dislike would be extremely helpful \$\endgroup\$ – user125391 Aug 21 '19 at 15:03
  • 1
    \$\begingroup\$ I didn't DV the question, but I suspect it's because the second-to-last paragraph reads like you're not entirely sure if it works. That said, I see no functional discrepancies that would prevent it from working. \$\endgroup\$ – Der Kommissar Aug 21 '19 at 15:14
  • \$\begingroup\$ And I only make that assumption because there's also a close-vote on the question for "Broken", though I don't see the legitimacy of that either. \$\endgroup\$ – Der Kommissar Aug 21 '19 at 15:16
  • \$\begingroup\$ The code works in tested before. Please consider edit the question because I am not sure I understand what's wrong... \$\endgroup\$ – user125391 Aug 21 '19 at 16:17
  • \$\begingroup\$ I would recommend that you edit your question to make it clearer it works. When your write "Hence, I fear I might need a tiny bit more "testing" to see..." that kind of makes it unclear if your code works. \$\endgroup\$ – IEatBagels Aug 21 '19 at 16:32

I recommend starting the script with a shebang so it can be executed as a program:


As there's nothing in here that isn't standard shell, then we can make it leaner by using plain POSIX shell instead:


I recommend set -eu, to cause the shell to abort in more error cases.

We can save one fork by using exec for the final command. In either case, the exit status should indicate whether the command completed successfully (if running from cron, consider using chronic when running the script, to only be mailed about the failures).

I question the use of zip as archive format - tar is generally installed on all Linux systems, and is the nearest we have to a standard. zip usually needs to be specifically added. Also, tar supports the -C option so that we can store relative paths in the archive, which may be useful if this backup is restored onto a new system with different file layout.

And whilst your quoting is good, it's slightly over the top - variable assignment is implicitly double-quoted.


date=$(date +%F-%T)
war=$HOME/public_html # Web Application Root

exec tar -C "$war" cfz "$archive" "$domain"

Finally, are you sure that's a good place to keep your backups? If the disk fails and you lose the site contents, you've probably lost the backups as well. I hope that this is only the first stage in making your backups and that you have a mechanism to transfer the archive files to offline media (preferably off-site) that you haven't shown us.

| improve this answer | |
  • \$\begingroup\$ Hi; thanks. I do have an external automatic backup system; AFAIK this entire shared server is backedup externally with daily backups for each user going 30 days backwards. \$\endgroup\$ – user125391 Aug 30 '19 at 15:25
  • \$\begingroup\$ I misunderstand this passage: And whilst your quoting is good, it's slightly over the top - variable assignment is implicitly double-quoted.; everything is double quoted both in my example and yours... What did you mean than? \$\endgroup\$ – user125391 Aug 30 '19 at 15:26
  • 1
    \$\begingroup\$ What I mean is that a="$b" can be written as just a=$b because word splitting and globbing don't occur in the context of variable assignment. It's not wrong to write the former, so if you like the consistency, just keep doing what you're doing! \$\endgroup\$ – Toby Speight Sep 2 '19 at 7:54

Well, to be honest I am not exactly sure what do you want to review :) This isn't a script. It is just standard zip command.

Maybe you should think about this: ${war}/mediawiki_general_backups/${domain}-directory-backup-${date}.zip. It is too long and ugly. Try to add more these things into your script and a readability will be lost.

I fear I don't have enough testing to ensure that the file was created,

If you want to be sure, that the zip command finished sucessfully, just test it.

#!/usr/bin/env bash

# Any subsequent(*) commands which fail will cause the shell script to exit immediately.
# https://stackoverflow.com/a/2871034/10814755
# Now i should trust the output of zip command. 
set -e

#domain=$1 <- It could be useful, isn't?

#I omit application root. I thing is safer to keep backups away.
backup_file="$(date +%F-%T).zip"

# You should trust the zip command, but sure is sure.
# So if backup file exist...
# ...and isn't empty...
if [[ -f ${backup_path}${backup_file} ]] && [[ ! -s ${backup_path}${backup_file} ]]; then
  #... then do something brave :)
  echo "Backup failed!"
  exit 1

Regards :)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy