0

I'm creating scheduled backups of a website (i.e. its "public_html" folder) via cron job and the first action is to compress that folder into a tar.gz backup ("public_html_date.tar.gz").

Sometimes I get an error by mail:

tar: /home/.../...: file changed as we read it

My questions are: - does this error stop the affected file from being archived into the tar? (i.e. skipped?) - does this error stop the cron process? (i.e. all subsequent files will not be archived into the tar?)

Finally: how reliable is this backup, is there a way to make it more reliable (without these errors) and what other more reliable strategies can I use?

Thank you.

1

does this error stop the affected file from being archived into the tar? (i.e. skipped?)

The check is done after archiving the file. So it was archived – but you don't know for sure whether it was fully archived; the archive might contain half of the old version and half of the new version.

does this error stop the cron process? (i.e. all subsequent files will not be archived into the tar?)

No, it continues archiving the next file. Although the tar process reports failure at the end, it will have created the full archive anyway.

(I mean you can always look inside your backups using tar -tf, and indeed you probably should look inside one of those failed backups just to be 100% sure.)

is there a way to make it more reliable (without these errors)

Important files in public_html don't usually change a lot. I would guess that most commonly these warnings come from cache directories used by your CMS, which is pointless to store and you can exclude from backups completely.

Aside from that, you could use storage snapshots if your server is set up to use LVM, or if the filesystem offers its own snapshot system (e.g. ZFS does). Then the process becomes "create snapshot – make a tarball of the snapshot – destroy snapshot".

what other more reliable strategies can I use?

Don't use the webserver as your primary storage location. Store the website's code (CMS or whatever) in a Git or Hg repository (it doesn't have to be on GitHub!), and have some process for deploying it to the webserver. It could start with something as simple as automating a git pull --ff-only after changes.

0

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.