[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.
---------------------------------------------------------------