Is there a chance to implement such a feature ?
Most of the time I use DCE to backup a server in case something happens to it.
But rather than manually selecting channels and choosing dates , a feature to export all channels and save time stamp to settings so that when I backup the server next time it will export from last time stamp rather than exporting again what I already exported in the first backup, and thank u.
Most likely not in GUI. I would advise to use CLI for such scenarios.
https://github.com/Tyrrrz/DiscordChatExporter/wiki/GUI%2C-CLI-and-Formats-explained#using-the-cli-
Hey there--I'm looking to clarify this issue for the sake of possible future reference.
I'm reading that @Chipsum would enjoy a feature where the app can take pre-existing export of a channel (or an entire guild/server in this case) and then update that export to match the current state/content of the server. That is to say, we have a backup of a server, and some new functionality could take that backup and update it by only downloading newer messages that occurred after that first backup was performed. While my quick look at the CLI doc indicates that the CLI provides commands for exporting entire servers this only solves half of issue, because it doesn't look like such "one-click backup" functionality is there. Currently, someone trying to maintain such a backup would have to look at the date/time of the last message saved in the most recent export/backup and then use that to retrieve only newer content by using the --after option. They would also end up with separate files/folders for each export (i.e. "update") they make, instead of one contiguous backup/export of the entire server history. Is this correct?
I do have a question/concern for @Chipsum or other users interested in this feature. It is possible that messages that we've already backed up can get edited at a later time. Unless this is considered to be OK and we choose not to care about these later edits (which I imagine would depend on the user), we would have to comb back through the entire history to capture these updates and reflect them in our existing backup as well. At this point, why bother with --after? Would it make more sense just to re-export the entire history?
As mentioned, I could imagine some users would be OK with not caring about edits to old messages. The use case described in this issue is such a scenario. This would allow us to only download newer messages and make maintaining such backups a lot more performant (as well as addressing the original desire for convenience). However, on top of the technical complexity of adding such a feature, users could get confused/frustrated when they see that previously-backed up messages that were edited after they were backed up would still appear in the backup with the original content (more specifically the content of the message at whatever time the export/backup was performed). I'm not sure if it's worth it.
edit: grammar/typos
I'm reading that @Chipsum would enjoy a feature where the app can take pre-existing export of a channel (or an entire guild/server in this case) and then update that export to match the current state/content of the server. That is to say, we have a backup of a server, and some new functionality could take that backup and update it by only downloading newer messages that occurred after that first backup was performed. While my quick look at the CLI doc indicates that the CLI provides commands for exporting entire servers this only solves half of issue, because it doesn't look like such "one-click backup" functionality isn't there. Currently, someone trying to maintain such a backup would have to look at the date/time of the last message saved in the most recent export/backup and then use that to retrieve only newer content by using the --after option. They would also end up with separate files/folders for each export (i.e. "update") they make, instead of one contiguous backup/export of the entire server history. Is this correct?
Heh, I didn't read so deeply into this, I thought the intent was just to export channel on a regular and semi-automated basis. If that's the case, creating a script that runs regularly and exports the channel since the last recorded timestamp is fairly easy. If the intent is to update existing file then yeah, such functionality is unavailable. The generated export files are not meant to be parsed back and while with some of them it could be easy (JSON), some others are more painful (HTML), and that's disregarding changes between versions.
@andrewkolos that's exactly what I wanted.
Not really updating the already exported messages and I would not like that for the sake of archiving messages in it's conditions.
But exactly to avoid backing up the whole server again , not only that it takes so long but it can fail when a network changes ( #402
We used to stop using some channels and break them into parts just to avoid the long process it takes to backup a heavy channel since it fails resuming (To be honest it's been a year without successfully backing up the whole server xD)
Why not split the export by dates? Given that the channel is so large that it takes so long, it probably doesn't make sense to export it all in one file anyway.
I don't know how much I can split when it comes to a heavy channel, But I will give it a try.
Thank you
You can use the --from/--to options (or their counterparts in the GUI) and make multiple exports this way. For example, you can have a sliding window of 1 month and have each export encapsulate 1 month of history. That way you will likely not need to export all of it each time either, but only the last month instead.