[GH-ISSUE #834] Export and import support #587

New issue

Closed

opened 2026-02-25 23:42:56 +03:00 by kerem · 1 comment

kerem commented

2026-02-25 23:42:56 +03:00

Owner

Originally created by @pfsmorigo on GitHub (May 30, 2023).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/834

I have a self hosted healthchecks instance and I had to change my VPS last month. I exported all the database and tried to import back but it's not being easy. Maybe if there is a option to export and import in some known format like json or yaml.

Is there something like that in the roadmap for this project? If not, maybe I can give a shot.

Originally created by @pfsmorigo on GitHub (May 30, 2023). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/834 I have a self hosted healthchecks instance and I had to change my VPS last month. I exported all the database and tried to import back but it's not being easy. Maybe if there is a option to export and import in some known format like json or yaml. Is there something like that in the roadmap for this project? If not, maybe I can give a shot.

kerem

2026-02-25 23:42:56 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:42:57 +03:00

Author

Owner

@cuu508 commented on GitHub (May 30, 2023):

I exported all the database and tried to import back but it's not being easy.

What issues did you run into?

Export/Import has been requested a few times, and I agree would be useful:

for moving account data when migrating servers (like in your case)
when moving from the hosted service to self-hosted (and vice-versa)
for self-service backups and recovery through the web UI ("oops, I deleted the wrong project, now what?")

For moving data between self-hosted instances, it could be as simple as a couple management commands – one command to produce a database dump, and another for importing it.

Export/import through web UI would be more tricky:

when exporting data, it should carefully select fields to include in the export. For example, exporting internal database IDs would be a security problem
when importing data, it would have to handle data conflicts. For example, what to do if we're importing a check, but a check with the same UUID already exists (and potentially belongs to a different user account)?
as Healthchecks evolves, and new database fields get added, the importing code would need to maintain backwards-compatibility for importing backups produced with older Healthchecks versions

It would have to be done very carefully, as there's lots of potential for unintended side-effects and security oopsies.

There was one time when a customer deleted a big project by accident and asked if it's possible to restore it. Obviously I could not restore the whole database, as it would roll back data for all other users. I restored a database backup to a separate system, and wrote export/import commands to export/import a single account. Here are the commands I used:

export.py:

from itertools import chain

from django.core.management.base import BaseCommand
from django.core.serializers import serialize

from django.contrib.auth.models import User
from hc.accounts.models import Credential, Profile, Project
from hc.api.models import Channel, Check, Flip, Notification, Ping


class Command(BaseCommand):
    help = """Export a single account's data in a JSON format."""

    def handle(self, *args, **options):
        email = "foo@example.org"

        user_q = User.objects.filter(email=email)
        credential_q = Credential.objects.filter(user__email=email)
        profile_q = Profile.objects.filter(user__email=email)
        project_q = Project.objects.filter(owner__email=email)
        check_q = Check.objects.filter(project__owner__email=email)
        channel_q = Channel.objects.filter(project__owner__email=email)
        ping_q = Ping.objects.filter(owner__project__owner__email=email)
        flip_q = Flip.objects.filter(owner__project__owner__email=email)
        notification_q = Notification.objects.filter(owner__project__owner__email=email)

        chained = chain(
            user_q,
            credential_q,
            profile_q,
            project_q,
            check_q,
            channel_q,
            ping_q,
            notification_q,
            flip_q,
        )

        print(serialize("json", chained, indent=2))

restore.py:

from django.core.management.base import BaseCommand
from django.core.serializers import deserialize


class Command(BaseCommand):
    help = """Export a single account's data in a JSON format."""

    def handle(self, *args, **options):
        f = open("foo_at_example_org.json", "r")
        for i, obj in enumerate(deserialize("json", f)):
            obj.save(force_insert=True)

            if i % 1000 == 0:
                print(i)

Note: I have not checked what happens with Postgres sequences if you use the above scripts to import data in an empty database.

@cuu508 commented on GitHub (May 30, 2023): > I exported all the database and tried to import back but it's not being easy. What issues did you run into? Export/Import has been requested a few times, and I agree would be useful: * for moving account data when migrating servers (like in your case) * when moving from the hosted service to self-hosted (and vice-versa) * for self-service backups and recovery through the web UI ("oops, I deleted the wrong project, now what?") For moving data between self-hosted instances, it could be as simple as a couple management commands – one command to produce a database dump, and another for importing it. Export/import through web UI would be more tricky: * when exporting data, it should carefully select fields to include in the export. For example, exporting internal database IDs would be a security problem * when importing data, it would have to handle data conflicts. For example, what to do if we're importing a check, but a check with the same UUID already exists (and potentially belongs to a different user account)? * as Healthchecks evolves, and new database fields get added, the importing code would need to maintain backwards-compatibility for importing backups produced with older Healthchecks versions It would have to be done very carefully, as there's lots of potential for unintended side-effects and security oopsies. --- There was one time when a customer deleted a big project by accident and asked if it's possible to restore it. Obviously I could not restore the whole database, as it would roll back data for all other users. I restored a database backup to a separate system, and wrote export/import commands to export/import a single account. Here are the commands I used: export.py: ```python from itertools import chain from django.core.management.base import BaseCommand from django.core.serializers import serialize from django.contrib.auth.models import User from hc.accounts.models import Credential, Profile, Project from hc.api.models import Channel, Check, Flip, Notification, Ping class Command(BaseCommand): help = """Export a single account's data in a JSON format.""" def handle(self, *args, **options): email = "foo@example.org" user_q = User.objects.filter(email=email) credential_q = Credential.objects.filter(user__email=email) profile_q = Profile.objects.filter(user__email=email) project_q = Project.objects.filter(owner__email=email) check_q = Check.objects.filter(project__owner__email=email) channel_q = Channel.objects.filter(project__owner__email=email) ping_q = Ping.objects.filter(owner__project__owner__email=email) flip_q = Flip.objects.filter(owner__project__owner__email=email) notification_q = Notification.objects.filter(owner__project__owner__email=email) chained = chain( user_q, credential_q, profile_q, project_q, check_q, channel_q, ping_q, notification_q, flip_q, ) print(serialize("json", chained, indent=2)) ``` restore.py: ```python from django.core.management.base import BaseCommand from django.core.serializers import deserialize class Command(BaseCommand): help = """Export a single account's data in a JSON format.""" def handle(self, *args, **options): f = open("foo_at_example_org.json", "r") for i, obj in enumerate(deserialize("json", f)): obj.save(force_insert=True) if i % 1000 == 0: print(i) ``` Note: I have not checked what happens with Postgres sequences if you use the above scripts to import data in an empty database.