id like to throw out there that an incremental is first on the chopping
block for deletion so you would have a tune your 'keep incrementals' quite a
lot to keep those around depending on your needs.
Additionally, the level of your incremental backups determins the efficiency
of the incremetal from the last full. if you have 6 levels of incremental,
each incremental will be from the last incremental which will be pretty
efficient BUT if your full period is 2 weeks, the 7th backup will not be
very efficient. even more, if you do just 1 full a month, you will have 4
or 5 inefficient incrementals and they drift out further and further per 6
day period.
the solution for me is to just change the incremental levels from 6 to 32.
I also have my full period set for 32 days because i am issuing a
Backuppc_dump command via a remote ssh script on my server to do a full
backup on the last day of business for the month(note, i use the
BackuPC_dump command because i turn -verbose on an send output to /dev/null,
the point being that my server is issuing the command via ssh and i want it
to wait until the backup is complete before moving on to the next task. if
someone knows how to get the BackupPC_servermsg to do the same thing let me
know).
i will be increasing the inc period to 2 days instead of .97 and issuing the
incremental backup command the same way so my setup will have the entire
month being done in incremental backups and a full backup being 1 day per
month, twice. once before the my server's month end process and once right
after. i will keep up to 65 incremental backups(none on weekends) to give 3
months of restorability down to the day.
by going just beyond the period of manual commands i hope to get a backup
even if something doesnt go right and i miss a backup.
On Nov 18, 2007 9:08 AM, Holger Parplies <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Les Mikesell wrote on 11.11.2007 at 12:24:16 [Re: [BackupPC-users] Full or
> Incremental.. What's the point?]:
> > Gene Horodecki wrote:
> > > [...] what's the point of having both full and
> > > incremental backups?
> > >
> > > [...] But with the
> > > awesome efficiences offered by BackupPC, it seems to me
> incremental/full
> > > becomes a mute point and a person might as well do an incremental
> every day
> > > perminently, or a full every day if you're worried about missing files
> with
> > > the incremental.. Either way, it's going to use the same amount of
> storage
> > > is it not?
> >
> > The difference is just in time, cpu use, and network bandwidth for the
> > backup runs to complete. [...]
> > If you have the bandwidth and time for all backups to complete, there's
> > nothing wrong with doing fulls every night.
>
> I think you are missing an important point: disk wear. We're not talking
> about 5% more or less time. On an example host (which may or may not be
> typical), I see a full backup taking 20 times as long as an incremental.
> The
> *full* takes 1-2 hours, so there's plenty of time to spare, but why would
> I
> want my disks on both BackupPC server and client machine to spend 1-2
> hours
> each night seeking all over the place, when a few minutes for an
> incremental
> backup will satisfy my data security needs? A full backup at the file
> level
> is never a linear disk operation, but even less so on the BackupPC server
> end, where file layout is optimized by the file system to fit the first
> backup rather than the current reference backup (and even that ignores
> files
> shared among clients or within one backup).
>
> The foremost concern are your requirements concerning backup correctness.
> Only a full backup is guaranteed to get an identical image of your file
> system, and that only if you have a snapshot mechanism on the client
> machine. Lacking that, incremental backups may, in fact, save a more
> consistent system state.
> Incremental backups are a compromise, but in most cases an extremely good
> one, more so for rsync than tar/SMB:
>
> > With tar and smb incrementals you may miss files that
> > have been copied or moved in ways that preserves an old timestamp
>
> ... which is any 'mv' or 'cp -p' (or equivalent operation), including
> directory renames. tar/SMB also cannot detect that files have been
> deleted,
> so they will be present in backups upto the next full.
> rsync is harder to fool. You need to modify a file, keeping file size and
> modification date as they were (this can be done, for instance, by
> swapping
> two files of identical size and modification date with three 'mv'
> commands).
> Chances are, this will happen next to never, but if you determine it is
> common enough to worry about at your site, you will have to figure it in.
>
> > rsync becomes less efficient as you get farther away from a full run.
>
> ... as do tar/SMB in exactly the same way. All changes relative to the
> reference backup need to be transferred. While this may still be faster
> than
> a full backup, the sum of (1 full backup + (N-1) incremental backups) will
> take less time than (N incremental backups) for an ever decreasing value
> of
> N. So, an occasional full backup will give you increased accuracy for
> free.
>
> As for incrementals of increasing level (meaning more recent reference
> points than the last full), the effort of constructing the backup view (
> i.e.
> reference point) grows with the level, so you can't do randomly high level
> incremental backups, even if your data security requirements would permit
> it.
>
> Regards,
> Holger
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
