Wipe all customer data from ISPConfig

Discussion in 'General' started by pyte, Nov 23, 2022.

  1. pyte

    pyte Well-Known Member HowtoForge Supporter

    Hi,

    is there a easy way to wipe all customer data from a ISPConfig mutliserver setup? Deleting every customer in the webinterface is tedious. I could delete every entry in the database related to customer data, but that feels like a brutal way. May there is a way to delete every customer + data through the API?
     
  2. pyte

    pyte Well-Known Member HowtoForge Supporter

    I deleted most of the stuff via DB and just rerun the migration toolkit. It seems to work flawless.

    Can anyone that knows more about the workings of the script tell me if the rsync commands do make a 1:1 copy?
    So if i run it 1 time and rerun it after changes(edits, adds, deletes) happend on the source, does it replicate that on the target?
     
  3. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    if you rerun rsync, anything changed on the source side will be replicated to the destination.
    with rsync you can select to have/not have anything that has been deleted from the source side also deleted from the destination.
    i've not looked at how the commands are written in the migration scripts, so i don't know if that option is used or not though.
     
  4. pyte

    pyte Well-Known Member HowtoForge Supporter

    Thats the relevant part. I'll have to migrate 700GB of maildata and then change DNS to point to the new MX server. If i can transfer all data in the evening, stop the mailservices, rerun the migration, change DNS, i will not have much downtime. If i have to stop the mailservices, then transfer 700GB of data, i will have a lot more downtime.
     
  5. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    that i can answer.. rerun the migration / rsync multiple times. until it completes quickly.
    then stop the mailservices, rerun the migration/sync a final time, then change the dns.
    that way, after the mailservices have been stopped, there should be a minimal amount of data to migrate. should all get done with very little downtime... done it that way myself and downtime was less than a minute.

    my recommendation would be to reduce ttl to a very short time period for any dns records that will need changing several days prior to the migration to ensure external dns servers won't cache the old server data for long by the time the migration happens. that should ensure that once you do run the migration, everyone quickly starts using the updated dns records.
     
    till, ahrasis and pyte like this.
  6. pyte

    pyte Well-Known Member HowtoForge Supporter

    Great thank you for the insight!
    Thank god we always set TTL of 5 min :)
     
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    Rsync is indeed getting very fast when you run it multiple times.

    Or use iptables or a minimal haproxy install to route the traffic to the new system. Basically:
    1) First rsync run.
    2) stop postfix + dovecot on old system.
    3) second rsync run.
    4) Route traffic to the new system using iptables or start haproxy with a minimal config to proxy all requests for the services to the new system.

    If you use IPtables, you can use something like this:

    Code:
    for P in 80 443 143 25 110 993 995 587 8080 8081 ; do iptables -t nat -A PREROUTING -p tcp --dport ${P} -j DNAT --to-destination 1.2.3.4:${P} ; done ; iptables -t nat -A POSTROUTING -j MASQUERADE
    or

    Code:
    for P in 80 443 143 25 110 993 995 587 8080 8081 ; do iptables -t nat -D PREROUTING -p tcp --dport ${P} -j DNAT --to-destination 1.2.3.4:${P} ; done ; iptables -t nat -D POSTROUTING -j MASQUERADE
    1.2.3.4 is the target IP address. I use this way e.g. when moving a system with the ISPConfig Migration Tool. The benefit of this over a short DNS TTL is that you switch traffic over instantly and if something worse happens, you can also reverse it instantly. And with DNS you can have the issue that some DNS cahces might not obey the short TTL.
     
    ahrasis, nhybgtvfr and pyte like this.
  8. pyte

    pyte Well-Known Member HowtoForge Supporter

    This is great, didn't even think about that.
    On a few system i can just set the old ip as a 2nd ip on the new server. This is possible for the Webservers.
    On the mailservers this is not possible as the old system are in another location, but with this method it should work just fine. Thank you so much :)
     

Share This Page