starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow exporting all data from UI #47

New Issue
Closed
opened 2025-12-29 15:30:39 +01:00 by adam · 4 comments
adam commented 2025-12-29 15:30:39 +01:00
Owner
Copy Link

Originally created by @bellwood on GitHub (Jun 28, 2016).

I'm running netbox in a dev VPS right now and have entered a sizable amount of data.

I'm going to want to move this to a production server and would really prefer not to have multiple exports (not sure if everything exports?)

Originally created by @bellwood on GitHub (Jun 28, 2016). I'm running netbox in a dev VPS right now and have entered a sizable amount of data. I'm going to want to move this to a production server and would really prefer not to have multiple exports (not sure if everything exports?)
adam closed this issue 2025-12-29 15:30:39 +01:00
adam commented 2025-12-29 15:30:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 28, 2016):

If you want to replicate the entire installation, you can just dump the SQL database:

sudo -u postgres pg_dump netbox > netbox.sql

And then load it on the new server:

sudo -u postgres psql -c 'create database netbox'
sudo -u postgres psql netbox < netbox.sql
@jeremystretch commented on GitHub (Jun 28, 2016): If you want to replicate the entire installation, you can just dump the SQL database: ``` sudo -u postgres pg_dump netbox > netbox.sql ``` And then load it on the new server: ``` sudo -u postgres psql -c 'create database netbox' sudo -u postgres psql netbox < netbox.sql ```
adam commented 2025-12-29 15:30:40 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Jun 28, 2016):

Definitely an option but my issue/use case for the issue was perhaps those either not comfortable on the command line or may not even have access.

For my specific purposes this obviously works just fine

@bellwood commented on GitHub (Jun 28, 2016): Definitely an option but my issue/use case for the issue was perhaps those either not comfortable on the command line or may not even have access. For my specific purposes this obviously works just fine
adam commented 2025-12-29 15:30:40 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 13, 2016):

I would agree that not all users of tool may be given access to the underlying DB.

I am exporting some of my data into the packetlife demo to make it more robust for some testing and new users to play around with. If a user wanted to export said data from the site, to their local install, they would not be able to for all sections. I know this would could also be tackled by #176, but I am all about UI standardization.

I think this should also cover allowing importing for all sections.

@ryanmerolle commented on GitHub (Jul 13, 2016): I would agree that not all users of tool may be given access to the underlying DB. I am exporting some of my data into the packetlife demo to make it more robust for some testing and new users to play around with. If a user wanted to export said data from the site, to their local install, they would not be able to for all sections. I know this would could also be tackled by #176, but I am all about UI standardization. I think this should also cover allowing **importing** for all sections.
adam commented 2025-12-29 15:30:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 22, 2016):

I don't think it makes sense to implement what is essentially a wrapper around a PostgreSQL dump. It's just more code to maintain that doesn't achieve anything a native PostgreSQL dump wouldn't. I understand that some people might not have direct access to the database, but that's an operational concern for the user.

@jeremystretch commented on GitHub (Sep 22, 2016): I don't think it makes sense to implement what is essentially a wrapper around a PostgreSQL dump. It's just more code to maintain that doesn't achieve anything a native PostgreSQL dump wouldn't. I understand that some people might not have direct access to the database, but that's an operational concern for the user.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#47
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?