►
From YouTube: Discussion about Gitaly Disaster Recovery plans
A
A
Okay,
so
I
have
the
first
item.
This
is
the
issue
that
we're
checking
for
this
discussion,
which
is
for
this
quarter
to
come
up
with
a
plan
to
see
like
what
we
can
do
for
Italy
Dr.
For
a
little
bit
of
background,
the
current
Dr
solution
for
giddly
is
to
use
snapshots.
We
have
established
that
the
RPO
for
snapshot
recovery
is
six
hours.
Rto
is
about
30
minutes.
A
Rpo
is
the
amount
of
potential
data
loss
and
the
reason
for
that
is
due
to
the
frequency
that
we
create
disk
snapshots
which
can
be
up
to
six
hours.
More
typically,
you
know
I
think
snapshots
are
more
typically
as
old
as
four
hours
for
our
test.
We
had
a
snapshot
that
was
around
I
think
between
one
and
two
hours
it
takes
about
30
minutes
to
restore
from
snapshot.
That's
the
time
to
create
the
disk
and
reconfigure
giddly
foreign.
A
B
A
A
A
A
The
main
one
of
the
main
reasons:
why
is
that?
There's
no
G
Cloud
terraform
support
yet,
which
makes
a
little
bit
difficult
to
automate,
there's
also
an
additional
cost
of
I
approximated
around
500
a
month
per
storage
node,
that's
in
in
addition
to
the
storage
cost,
so
you
would
have
the
storage
cost
in
object,
storage
for
the
data
that
we're
backing
up
plus
500
per
month.
For
you
know,
each
storage,
node
and.
B
A
A
One
of
the
things
that
attracted
me
to
the
solution
was
with
gcp
snapshots.
We
don't
have
any
control
over
when
full
or
incremental
snapshots
are
taken.
We
had
a
conversation
with
Google
about
that
and
they
said,
there's
really
nothing
that
we
can
do
to
control
when
when
that
happens,
and
that's
the
reason
why
our
RPO
can
be
so
long,
because
these
full
snapshots
take
a
significant
longer
amount
of
time
compared
to
the
incrementals
with
the
pack
of
Appliance.
We
have
a
lot
more
control
over
that.
So
that's
one
benefit.
A
B
A
Yeah
I
mean
I
I'm,
going
to
I'm
kind
of
going
in.
With
that
assumption
that
we
would
advertise,
you
know
different
RPO
RTO
I
mean
I
yeah
different
RPO
RTO,
depending
on
the
the
plan,
and
that
would
probably
be
okay,
but
maybe
we
need
to
explore
that
a
bit
further
yeah
so
for
B.
So
for
B2
yeah.
You
had
some
comments
here.
Steve.
A
B
B
Yeah
so
I
I
guess
we'll
have
to
do
a
full,
detailed
cost
analysis
of
the
current
setup.
If
that
makes
sense
before
we
can
do
a
decision
on
this
as
well
and
have
like
a
benchmarking
for
the
regional
PD
balanced
and
see
like
okay,
if
we
deploy
a
gitile
node
with
regional
BD
balance
like
how
quick
is
it
going
to
be
to
recover
if
something
goes
wrong
there
and
things
like
that
right.
A
And
the
backup,
Appliance
and
the
regional
storage
isn't
I,
don't
think
is
a
good
like
I
mean
obviously
the
the
backup
Appliance
has
still
has
an
RPO
issue.
When
I
asked
gcp
about
like
how
long
these
incrementals
will
take,
they
said:
okay,
they're
gonna
probably
take
around
the
same
amount
of
time
as
snapshots,
so
we're
still
looking
at.
B
Yeah
a
little
loss
so
and
and
the
action
items
I'm
writing
down
something.
So
if
you
scroll
down
from
your
screen,
so
maybe
we
need
to
create
some
creative
criteria
for
the
best
option
right,
which
would
be
costs,
of
course,
for
for
current
utility
Fleet.
So
let's
say:
okay,
let's,
for
example,
the
backup
storage,
the
backup
Appliance
is
going
to
cost
us
x
amount
of
dollars
per
month,
but
the
89
hours
that
we.
B
B
A
B
B
So
maybe
we
can
get
some
more
data
on
that
like
get
like
an
Excel
sheet
or
whatever
like.
This
is
how
much
it's
gonna
cost
us
on
all
of
them
and
then,
if
we
want
to
make
regional
balance
disk
storage
even
more
attractive,
we
can
say,
like
here's
gonna,
be
the
third
storage
with
caveat
that
we
need
to
implement
all
that
logic,
which
is
also
a
bunch
of
work.
That
needs
to
be
done
and
it's
more
of
a
cost
optimization
than
anything
else.
I
guess.
B
A
A
B
A
A
A
A
A
B
A
B
A
Yeah
the
the
the
sessions
we've
had
with
them
have
all
been
async
and
are
captured
in
the
docks,
and
this
was
them
going
to
the
product
teams
to
answer
questions
that
we
had
with
regard
to
snapshot,
frequency
and
the
the
appliance,
the
backup
Appliance.
So
yeah,
that's
pretty
much.
All
we've
done
so
far.
I
think
we
could
maybe
maybe
in
this
epic
we
can
once
we
have
like
a
very
high
level
idea
of
like
cost,
and
you
know
calls
for
the
two
options
and
the
I
guess
the
impact.
B
A
B
A
A
B
B
A
Okay
sounds
good,
so
I'm
gonna
take
the
action
to
create
the
epic
and
add
issues.
I'll
also
add
an
issue
for
this
meeting
with
the
solutions
architect,
so
we
can
just
track
it
and
I'm
expecting
like
maybe
some
of
this.
We
can
start
in
January,
but
it's
going
to
definitely
bleed
into
the
next
quarter.
Yeah.
A
A
I
I
think
that's
kind
of
going
to
be
up
to
whether
you
have
bandwidth
to
help
you
know
like
then
you
I,
I,
probably
don't,
but
at
least
probably
not
in
this
quarter,
but
maybe
maybe
we
can.
We
can
work
together
on
some
of
this
stuff
yeah
and
from
the
giddly
team.
I
think
what
I
would
like
to
understand
is
you
know
where
we
are
with
the
rav3
architecture
and
where
we
are
with
tiered
storage.
If
that's
in
the
road
map,
but
like.
B
B
A
B
You
know
what
that
means,
and
it
means
like
it's
another
few
more
quarters
to
deploy
it
on
github.com,
so
I
would
say
it's
I
would
say
like
a
year
or
two
away
to
be
honest
to
for
it
to
be
for
the
mature
of
our.com
and
then
that
implements
storage
as
well
right,
so
yeah
and
I
feel
like
that
is
very
far
away.
Unfortunately,.