next »

[dink]

I want to have a good backup for my debian install, so I use this via cli:

Code:

tar cvpzf backup.tgz /

I have used this before and it worked.  At least I think it worked.   

I just did some changes and re ran the backup.  I got a couple of messages from tar:

tar: /: file changed as we read it
tar: Error exit delayed from previous errors

I don't remember that last line from before.  Any clues for a clueless n000b?

[perkiset]

It means that a file was touched while it was being tarballed or compressed.

Go again, ought to be fine. I had this trouble with my offsite scripted backup of my databases - the DB files would change while I was tarballing ... so I killed the webserver while backing up and things got back to normal.

Ifn you choose such a thing, my method was rather simple: if a "stub" file exists, the I mod_rewrite the website into a stub page. Otherwise, behave normally. Looks like this:

RewriteCond /www/sites/stubFile.txt -f
RewriteRule ^(.*)$ /www/sites/stubFiles/theFile.html [L]

So my backup script first would touch (create) a file called theFile.html (names changed to protect the innocent) and if Apache sees it, nothing goes into my dynamic web sites ie., no touches on the DB and I'm all good. Last step is to rm -f the file and the website is back online. The HTML file simply says something like "We're in the middle of our nightly backup, give us a minute" or some such.

Now my primary backups are slaved databases on different machines, but there is a similar problem because the slaves see activity in almost realtime with the masters. So I issue a SQL command to stop the slave, wait a minute, do the backup and then start the slave again, which brings my backup back up to date with the master.

Just gear turners my friend, hope this helps,
/perk

[dink]

Aha.  Yepster, makes sense to me now.  I have a cron going that has postfix checking the email situation.

If that is the file that was touched while the script was trying to get it backed up, then prolly everything
will be hunky-dory.

I'm gonna need to put the backup operation in an automagic mode at some point, so I'll investigate what
you've posted above.  If I get tied up in my pantyhose (again) I'll ping back here.

Thanks my friend.

[thedarkness]

I want to have a good backup for my debian install, so I use this via cli:

Code:

tar cvpzf backup.tgz /

Errrrr..... so where is this backup.tgz being created? If it's anywhere under / your problem is pretty obvious, at least to me.

Cheers,
td

[dink]

Like the snippet said:  /

[thedarkness]

Dink,

So you are backing up "/" to a file called "/backup.tgz"?

I've never done this but it strikes me as whack. Backing up a directory that contains the backup file == weirdness to me. However I just did some tests and it works and does not error so I apologise for shooting my mouth off.

Cheers,
td

[dink]

No, I delete the old backup before I run the current one.  (I keep a copy on my pc at home just because...)

No probs.  I didn't think you were shooting off anyways.  I allus need help and don't have a thin skin in
any case.  So, all help appreciated.

fyi.  As I understand it the code could be run like so:

Code:

tar cvpzf backup_1.tgz  --/backup.tgz /

...if you wanted to keep multiple backups on the server. 

I'm working on a lil shell script to do the backup from chron.  The backup would be named for the date/time
it was run.  Just have to figger out how not to back up the old backups.   

[thedarkness]

The command "date +%d_%m_%Y" may be handy for you although you prolly need the ass-backward yank format :-)

Cheers,
td

[dink]

Yours looks more interesting than what I've been looking at:

Code:

tar cvpzf backup-`date +%F`.tgz /

you prolly need the ass-backward yank format

Ya.  I likes it when it's back-asswards.   

[thedarkness]

haha, now we're talking ISO format............