The backup scenarios described below seem to be the main ones that affect me directly (apart from the obvious ones like changing firewalls, DNS records, SSH logins etc) It seems to me that the obvious answer seems to be you should make changes first
 
Keith

On 29 October 2011 10:43, Andy Smith <andy@bitfolk.com> wrote:
Hello,

We're now very close to the point when we need to begin getting you
all to renumber your IP addresses. We are not there yet, but here is
some more info:

   https://tools.bitfolk.com/wiki/Renumbering_out_of_212.13.194.0/23

Before finalising the procedure and sending out instructions I could
use some feedback from you on a couple of points. These involve
situations where BitFolk is contacting you by IP address.

- BitFolk Backups

 Our backup servers are doing rsync-over-SSH by IP address.

 If we change the IP addresses our side then your backups stop
 working until you make your change.

 If we don't change the IP addresses our side then your backups
 will break when you make your change, and then you would need to
 contact support to get the change done.

 Which would be preferred?

- Nagios checks

 Many of you have Nagios checks. These are done by IP address.

 If we immediately make the change on our side then alerts will
 start to fire for you, and will not right themselves until you
 complete the IP address change on your side.

 If we don't make the change on our side then as soon as you make
 your change, alerts will start to fire and then you'd have to
 contact support to ask for the monitoring to be fixed.

 I have a strong preference for us making the change as soon as you
 have the info to make the change your side, so that the monitoring
 fixes itself as you do the work.

 Any other ideas how to do it?

- Old rsync-style zone transfers

 Some of you still have DNS secondary services driven by zone files
 that we are rsyncing from you. This is happening by IP address.

 This service was deprecated years ago, since everyone got enough
 RAM to run a proper DNS server for this purpose.

 I would like to finally retire this service. How much time would
 people like to stop relying on it and switch to running a real DNS
 server?

- DNS slaves

 Those of you who have secondary DNS services will be running your
 own DNS server on your VPS and we'll be doing AXFR to that IP
 address.

 The DNS secondary service comes with Nagios monitoring, so as soon
 as we switch the IP configured on our side then monitoring as
 mentioned above will begin to alert.

 There can be multiple masters, so what we could do is set both old
 and new IP addresses so that zone transfers can continue to take
 place, but our monitoring can only have one IP address.

 With that in mind I think I would prefer to set both old and new
 IPs as masters, let monitoring alert for your TCP/53 and that will
 fix itself as your sort out your new IP address.

 Any other ideas how to do it?

As far as possible in all cases above I would like to avoid the
situation where we have to chase individual customers one-on-one
about things that suddenly stopped working.

I can imagine this might not be avoidable—particularly in the case
of the backups—so if we have to do it, we have to do it.

Cheers,
Andy

--
http://bitfolk.com/ -- No-nonsense VPS hosting

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAk6ryrYACgkQIJm2TL8VSQv2+ACgmHPWSk7fzBZJ8MEP0kFzigfX
m3UAnij1d8w1e+qbuVYQclCuWST6nQVS
=p30y
-----END PGP SIGNATURE-----

_______________________________________________
announce mailing list
announce@lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce

_______________________________________________
users mailing list
users@lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users




--
Keith Williams

If the only tool you have is a hammer, you tend to see every problem as a nail.
  - Abraham Maslow

·Ó´Õä´é´Õ  ·ÓªÑèÇä´ªÑèÇ