before whatever you specify
on the command line. So if your master2.conf is pretty much a copy of
master.conf, you're loading all that stuff twice.
dirvish-runall doesn't use the contents of Runall:. I'm pretty sure it
just goes off of the bank: data.
I run a variation of that to
Jon Radel wrote:
>
> dirvish-runall doesn't use the contents of Runall:. I'm pretty sure it
> just goes off of the bank: data.
Which is something he shouldn't have written.
Please read:
dirvish-expire doesn't use the contents of Runall:. I'm pretty sure
ish
Pretty close. There's no particular need to run dirvish-expire on your
new 4pm vault twice a day unless you really want to. A dirvish-expire
w/o any options looks in all your banks.
In other words:
dirvish-expire [at 3am]
dirvish-expire --v
s time machine working for 7 hour
jumps. Hard to tell sometimes.
--Jon Radel
___
Dirvish mailing list
Dirvish@dirvish.org
http://www.dirvish.org/mailman/listinfo/dirvish
tly as specified and I, for one, don't find it constraining. I
freely grant that some people might find the additional functionality
useful.
Or to put it another way, the fact that scope creep hasn't fully set in
yet is not a bug. :-) :-)
This is not necessarily the same as the last successful backup
to be created. Unless all your backups use the same retention period,
the chances are pretty good that the last backup to be made is not the
one that'll hang around forever.
--Jon Radel
___
kups are
indeed bad, delete them all and do an -init from scratch.
--Jon Radel
___
Dirvish mailing list
Dirvish@dirvish.org
http://www.dirvish.org/mailman/listinfo/dirvish
monday image without having any problems ?
>
Unless you want to restore a file that was captured only in that backup.
:-) If you delete the last successful backup, you'll have to run
dirvish with the --init option again. Other than that, you can delete
an
[EMAIL PROTECTED] wrote:
> Hello,
>
> Thanks for your reply.
>
> Selon Jon Radel <[EMAIL PROTECTED]>:
>
>> Rémi Boulle wrote:
>
>>> For what I understood dirvish write only the changed parts of the
>>> changed files.
>> While, i
ough by default it will consider the image failed.
My dirvish installation certainly retries on missing files. It only
considers the backup failed if it (or presumably another error) happens
on every attempt.
--Jon Radel
___
Dirvish maili
ain, iterate.
Works for me, though I'll admit a bit more planning up front *might*
reduce the overall effort. In any case, dirvish keeps right on chugging
away.
--Jon Radel
smime.p7s
Description: S/MIME Cryptographic Signature
___
Dirvish mailing
and would be much happier to
see a 12-day old daily backup get sacrificed than a 3-month old monthly
backup. My first thought would be calculate, for each backup, the
percentage of the duration between creation and expiration which has
elapsed and delete backups for which that value is the h
Joel Franco wrote:
On Qua Mai 02 07 22:41, Jon Radel wrote:
2) I don't think that you need to make any changes to dirvish at all.
Writing a separate expiration script which can parse that line out of a
config file and then deletes backups as necessary should be quite feasible.
This
reates the base directory for that day
quick.
--Jon Radel
___
Dirvish mailing list
Dirvish@dirvish.org
http://www.dirvish.org/mailman/listinfo/dirvish
Bernd Haug wrote:
> I'm not sure if you've been using Macs; but /I/ simply think that they
> should start at writing one decent file system for that thing - i.e.,
> the basics - before going overboard with luxury items like hyper-modern
> backup systems.
ZFS is c
ne, but
your mileage depends entirely on the amount of data, profile of file
sizes, speed of network connection, and/or speed of disks. And, yes,
following backups will probably be much faster but, again, your mileage
:-)
--Jon Radel
smime.p7s
Descri
words.
Now, that all said, if you want to patch dirvish-expire to optionally
never expire the most-recently-made good backup, instead of only never
expiring the last-to-expire good backup, I'm sure that said patch will
greeted with joy widely enough to make it worth your while to
rectories, a and b, which are
both 5M big, but the contents of the directory they're in, is also only
5M in size.
You can find a more detailed discussion of this whole matter, and how
hard links work in practice, in the archives for this list.
--Jon Radel
smime.p7s
Descripti
us about the why of my setup... I have two backup
servers in two different cities which essentially take turns backing up
the different vaults, except on Sundays, when they both backup
everything, and set it to a longer expire time. I don't much care if
the client disks thrash a little bit at 2a
probably missing /usr/local/sbin)
or set it in your crontab, mileage depending on what else you have in
your crontab, etc., etc.
--Jon Radel
smime.p7s
Description: S/MIME Cryptographic Signature
___
Dirvish mailing list
Dirvish@dirvish.org
http://www.dirvish.org/mailman/listinfo/dirvish
start the backup?
--Jon Radel
smime.p7s
Description: S/MIME Cryptographic Signature
___
Dirvish mailing list
Dirvish@dirvish.org
http://www.dirvish.org/mailman/listinfo/dirvish
f file system the
> backups are being copied to...if your target filesystem does not accept
> hard links, it's a tough problem for dirvish.
And while we're at it, the log file matching that summary file to give a
bit more information on what rsync did.
And which version of rsync
Jens Lang wrote:
> Jon Radel schrieb:
> [...]
>> Number of files: 155036
>> Number of files transferred: 942
>> Total file size: 60891647542 bytes
>> Total transferred file size: 208591096 bytes
>> Literal data: 13875619 bytes
>> Matched data: 19471579
er, or both, ends of their rsync sessions.
Thanks.
--Jon Radel
smime.p7s
Description: S/MIME Cryptographic Signature
___
Dirvish mailing list
Dirvish@dirvish.org
http://www.dirvish.org/mailman/listinfo/dirvish
s after every backup? Now,
admittedly, if you configure something like SELinux with great care, you
can make twiddling the SUMS file after the fact very difficult, but if
you do that, you could probably make it equally difficult to tamper with
the backups in the first place.
--Jon Rade
hen use a 9 inch fan to blow air across the whole row
of equipment (there are some cable modems and the like in there as
well). I have to replace the fan about once a year, but meanwhile the
equipment stays *much* cooler.
Of course, figuring out how to power down the drives and skipping the
fan wou
t are dependent on your configuration, so
you'd probably be better off finding the file and then doing a "pwd".
I would recommend looking around in the file structure of your backups
until you have a general sense of how dirvish puts data together.
--Jon Radel
j...@radel.com
s
Just remember that some drives have to be at the leading edge of the
failure bell curve, and sometimes it's just your turn.
Some brands will tell you warranty status based on serial number
somewhere in the support section of their website.
--
--Jon Radel
j...@radel.com
smim
doesn't mean they're not out there.
Personally, when I have something blow up, one of my actions on my
checklist is to add a decade to the expiry time on the most promising
image in every dirvish vault that backs up what are now smoking ruins.
--
--Jon Radel
j...@radel.com
___
On 3/16/11 1:05 PM, Dave Howorth wrote:
>
> Jon Radel wrote:
>> I was nodding my head in agreement to your message until the very end of
>> this. This has come up before on the mailing list. If I understand the
>> OP correctly, his primary desire is that dirv
entage of the files have changed, etc., etc.
The biggest problem I see is translating the "just do what I mean"
heuristics into algorithms that a significant percentage of dirvish
users can agree on. ;-)
--
--Jon Radel
j...@radel.com
__
31 matches
Mail list logo
