[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interrupted backups



--As of March 21, 2014 3:13:58 PM +0000, John Gamble is alleged to have said:

Thanks again for your reply.  Still slightly confused about this process
though….  In the scenario I'm thinking about, 'backup-wednesday.part'
and 'backup-thursday' wouldn't have any common files (or blocks of data).
The complete archive would be the sum of 'backup-wednesday.part' and
'backup-thursday'.  Therefore, how is it possible to delete
'backup-wednesday.part'?  Is it, in fact, impossible to do so in this
case?  If so, is there any way to create a single complete backup/archive
from two or more partial ones, that were formed by premature termination
of a backup.

If there are truly no files in common, then deleting backup-wednsday.part deletes all the files (or: data blocks containing files) in that backup. But if that's the case, then the complete archive is *not* the sum of the two: You have two separate archives.

What I think you want to do is back up a list of files, break up the connection, then finish the backup of that list of files at another time. Tarsnap can do this easily, as long as you don't overthink it. ;) In particular, do *not* try to exclude the files that you have 'successfully' backed up on Wednesday from the Thursday backup. Just let it back up everything again; tarsnap will figure out what it has already sent and what it hasn't, and handle things appropriately.

Tarsnap is designed to handle nicely the common backup situation where you are backing up a large number of files on a regular basis, without caring or knowing when they are changed. (Or created, or deleted.) You give it a list of files and it backs up *what it hasn't backed up before* of that list. Partials are just backups that didn't run to completion: They don't have all the files they are supposed to, but other than that they are normal archives. (There is no difference to *tarsnap* between a partial and a full backup - it just names them as partials so that the *user* can tell the difference.)

Another way to look at this (slightly inaccurate, but will probably help understanding): The list of files in a backup is created at the start of the backup process. Tarsnap turns that into a list of data blocks that it has to save to the server. It then checks to see if it already has any of those blocks on the server, and skips those, while sending the rest. A partial backup is one where that didn't complete - but the blocks that it has sent are still there. If you then create a new backup with the same list of files, there will be more blocks tarsnap can skip sending. (But note that the *list of files* is identical - tarsnap just didn't complete sending them the first time.)

I'm asking all this because given the speed of my upload connection, I
know that I'll have to stop the initial backup before it completes.  Just
wanted to make sure that I'll ultimately be able to create a complete
backup.

Yes, just keep creating the backup with the same list of files and let tarsnap handle sending what data it needs to. (My initial upload of one of my archives took over a month, and was broken up several times, but created a complete archive in the end.)

A couple of minor queries:

1).  To terminate an ongoing backup, is the command ^Q?

That or ^C (SIGINT), or SIGQUIT will work, in my experience.  ;)

2).  While the backup is ongoing, is it OK to use the computer as normal?

Yes. Be aware that there will be a fair amount of IO going on, both disk and network, but other than that you should have no problem.

If you are working with the files that you are backup, be aware that tarsnap does not by default do a 'point in time' backup - it will backup the file in the state it is in when it gets to it, even if it's been edited since the backup started. (If it gets deleted, you'll get an error message, but tarsnap will continue on.) If you need a point in time backup, you'll have to look at filesystem snapshots. Most of the time you don't, unless you are trying to back up an active database or something like that.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------