starred/sms-backup-plus-jberkel

Fork 0

mirror of https://github.com/jberkel/sms-backup-plus.git synced 2026-04-25 17:05:59 +03:00

[GH-ISSUE #749] Additionally backup to a local file #618

New issue

Closed

opened 2026-02-26 01:31:07 +03:00 by kerem · 21 comments

kerem commented

2026-02-26 01:31:07 +03:00

Owner

Originally created by @ghost on GitHub (Apr 11, 2017).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/749

I can't find(if there is) an option for ONLY local backup. No G, no private.

Originally created by @ghost on GitHub (Apr 11, 2017). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/749 I can't find(if there is) an option for ONLY local backup. No G, no private.

kerem

2026-02-26 01:31:07 +03:00

closed this issue
added the
feature-request

question

cloudless
labels

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@Nicop06 commented on GitHub (Apr 19, 2017):

I wanted to ask the same question. I had a look at the source code and it seems that the only backup option implemented is the IMAP option. Also, adding a local backup option might not be trivial.

@jberkel Is it a feature you are interested in? I can work on a pull request.

@Nicop06 commented on GitHub (Apr 19, 2017): I wanted to ask the same question. I had a look at the source code and it seems that the only backup option implemented is the IMAP option. Also, adding a local backup option might not be trivial. @jberkel Is it a feature you are interested in? I can work on a pull request.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@chaoqing commented on GitHub (Feb 13, 2018):

This would be great! Once created a local backup in the local storage, the termux software can be used to analysis the message or call log and do anything I want. @Nicop06 do you have any plan implement this?

@chaoqing commented on GitHub (Feb 13, 2018): This would be great! Once created a local backup in the local storage, the `termux` software can be used to analysis the message or call log and do anything I want. @Nicop06 do you have any plan implement this?

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@Nicop06 commented on GitHub (Feb 13, 2018):

@chaoqing I completely forgot about that. I currently don't have time to work on it. I will update this issue if I find the time to start implementing this feature unless someone else wants to work on it.

@Nicop06 commented on GitHub (Feb 13, 2018): @chaoqing I completely forgot about that. I currently don't have time to work on it. I will update this issue if I find the time to start implementing this feature unless someone else wants to work on it.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@jberkel commented on GitHub (Feb 13, 2018):

What do you mean by "local backup"? Copying the data to a database/csv file?

@jberkel commented on GitHub (Feb 13, 2018): What do you mean by "local backup"? Copying the data to a database/csv file?

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@Nicop06 commented on GitHub (Feb 13, 2018):

On the sd card. So that it can be exported using cloud synchronization applications for instance.

@Nicop06 commented on GitHub (Feb 13, 2018): On the sd card. So that it can be exported using cloud synchronization applications for instance.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@jberkel commented on GitHub (Mar 28, 2018):

I'd prefer (esp. for privacy reasons) not to store a copy of the user's data locally.

@jberkel commented on GitHub (Mar 28, 2018): I'd prefer (esp. for privacy reasons) not to store a copy of the user's data locally.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@AeliusSaionji commented on GitHub (Mar 28, 2018):

But uploading to Google is an A-OK privacy move?

It's already locally stored on the phone. We just want more flexibility with that.

@AeliusSaionji commented on GitHub (Mar 28, 2018): But uploading to Google is an A-OK privacy move? It's already locally stored on the phone. We just want more flexibility with that.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@jberkel commented on GitHub (Mar 28, 2018):

@AeliusSaionji it's a question of responsibility: if they are stored on Gmail I'm not responsible for privacy issues (Google is), but storing locally is a different thing (cf. the privacy policy)

Aren't there already dedicated apps which just do local backups?

@jberkel commented on GitHub (Mar 28, 2018): @AeliusSaionji it's a question of responsibility: if they are stored on Gmail I'm not responsible for privacy issues (Google is), but storing locally is a different thing (cf. the [privacy policy](https://jberkel.github.io/sms-backup-plus/privacy-policy/)) Aren't there already dedicated apps which just do local backups?

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@AeliusSaionji commented on GitHub (Mar 28, 2018):

If there's a solution on Fdroid that still works on Oreo and supports restoring, I haven't seen it.

@AeliusSaionji commented on GitHub (Mar 28, 2018): If there's a solution on Fdroid that still works on Oreo and supports restoring, I haven't seen it.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@jberkel commented on GitHub (Mar 28, 2018):

Specifically open source apps I don't know, was thinking of "SMS Backup & Restore" (which uses some XML format I believe)

@jberkel commented on GitHub (Mar 28, 2018): Specifically open source apps I don't know, was thinking of "SMS Backup & Restore" (which uses some XML format I believe)

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@Woi commented on GitHub (Apr 2, 2018):

A common use case would be migrating from an old to a new phone. Especially for users with google free phones.

@Woi commented on GitHub (Apr 2, 2018): A common use case would be migrating from an old to a new phone. Especially for users with google free phones.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@rancidfrog commented on GitHub (Apr 27, 2018):

@jberkel Privacy concern is exactly why I prefer to store locally.
Also, "SMS Backup & Restore" seems to have been sold to some company. Before it was a one man show - Ritesh Sahu, now SyncTech Pty Ltd controls the app.
There has been some bad precedents on companies buying popular small apps.
It would be great to have an option to store it locally ( internal sd, as external sd causes headaches for developers due to googles lack of proper code regarding external devices).
Regarding privacy concerns of local storage, a popup disclaimer could warn users about any privacy issues due to saving data locally, i.e. easily accessible to anyone etc.

@rancidfrog commented on GitHub (Apr 27, 2018): @jberkel Privacy concern is exactly why I prefer to store locally. Also, "SMS Backup & Restore" seems to have been sold to some company. Before it was a one man show - Ritesh Sahu, now SyncTech Pty Ltd controls the app. There has been some bad precedents on companies buying popular small apps. It would be great to have an option to store it locally ( internal sd, as external sd causes headaches for developers due to googles lack of proper code regarding external devices). Regarding privacy concerns of local storage, a popup disclaimer could warn users about any privacy issues due to saving data locally, i.e. easily accessible to anyone etc.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@jghq commented on GitHub (Sep 9, 2018):

I just want to add my voice to those requesting a local import/export. A trusted open source application is not in the same class as some shady app from the Play store that does who knows what with our data. A local file can be deleted after use. We would have to run a local IMAP server to be able to achieve that level of control with this app without local import/export, and that seems a bit of an overkill.

@jghq commented on GitHub (Sep 9, 2018): I just want to add my voice to those requesting a local import/export. A trusted open source application is not in the same class as some shady app from the Play store that does who knows what with our data. A local file can be deleted after use. We would have to run a local IMAP server to be able to achieve that level of control with this app without local import/export, and that seems a bit of an overkill.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@lesmana commented on GitHub (Jul 26, 2019):

as a half workaround there is "slight backup"
https://f-droid.org/en/packages/de.shandschuh.slightbackup/
https://github.com/handschuh/Slight-backup
unfortunately already 5 years old and maintainer seems to be dead.
i was able to export smses. it produces an xml file. but i was not able to import. it just says import successful but no sms imported.

@lesmana commented on GitHub (Jul 26, 2019): as a half workaround there is "slight backup" https://f-droid.org/en/packages/de.shandschuh.slightbackup/ https://github.com/handschuh/Slight-backup unfortunately already 5 years old and maintainer seems to be dead. i was able to export smses. it produces an xml file. but i was not able to import. it just says import successful but no sms imported.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@hydrargyrum commented on GitHub (Nov 9, 2019):

What about MMSes? Neither does SlightBackup nor SMSGate backup them. It would be useful to have sms-backup-plus to save them locally.

@hydrargyrum commented on GitHub (Nov 9, 2019): What about MMSes? Neither does SlightBackup nor SMSGate backup them. It would be useful to have sms-backup-plus to save them locally.

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 22, 2020):

I suggest, if this is to be implemented, that it uses MailDir format, rather than combining multiple messages in an archive (eg, XML). That means you don't need to worry about combining or overwriting such files when you export, since every individual message is its own file with a UUID for a name.

This would behave similarly to an IMAP service, so it may simplify some of the coding needed.

Taking that one step further, one possible approach would be to install an IMAP server on the phone, as a separate app, with its own privacy policy. Does anyone know of such a thing?

@kurahaupo commented on GitHub (May 22, 2020): I suggest, if this is to be implemented, that it uses MailDir format, rather than combining multiple messages in an archive (eg, XML). That means you don't need to worry about combining or overwriting such files when you export, since every individual message is its own file with a UUID for a name. This would behave similarly to an IMAP service, so it may simplify some of the coding needed. Taking that one step further, one possible approach would be to install an IMAP server on the phone, as a separate app, with its own privacy policy. Does anyone know of such a thing?

kerem commented

2026-02-26 01:31:07 +03:00

Author

Owner

@hydrargyrum commented on GitHub (May 22, 2020):

@kurahaupo, Epistolaire has a SMS/MMS-JSON to Maildir converter, but this specific converter is written in Python. You might still be interested: https://github.com/hydrargyrum/epistolaire/tree/master/converters/maildir
Python interpreters exist on Android, and if the need arises, the converter could be ported to Kotlin with some effort.

Some of the design decisions were:

each conversation on SMS/MMS app corresponds to one mail thread
each conversation has a virtual root message which doesn't exist, i.e. it's not present in the maildir
all messages in a conversation include a References header pointing to that root message
this is useful for subsequent backups, the root message id always stays the same for a conversation, even in the case where a backup has no common message with a previous backup
each SMS header Message-ID is a hash of sender + datetime, to have a stable id across backup

@hydrargyrum commented on GitHub (May 22, 2020): @kurahaupo, Epistolaire has a SMS/MMS-JSON to Maildir converter, but this specific converter is written in Python. You might still be interested: https://github.com/hydrargyrum/epistolaire/tree/master/converters/maildir Python interpreters exist on Android, and if the need arises, the converter could be ported to Kotlin with some effort. Some of the design decisions were: - each conversation on SMS/MMS app corresponds to one mail thread - each conversation has a virtual root message which doesn't exist, i.e. it's not present in the maildir - all messages in a conversation include a `References` header pointing to that root message - this is useful for subsequent backups, the root message id always stays the same for a conversation, even in the case where a backup has no common message with a previous backup - each SMS header `Message-ID` is a hash of sender + datetime, to have a stable id across backup

kerem commented

2026-02-26 01:31:08 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 23, 2020):

@hydrargyrum thanks for those very useful points.

I've added some improvement suggestions for you.

I'll look into how threading is currently implemented in SMS Backup+ to see whether these ideas can be incorporated.

@kurahaupo commented on GitHub (May 23, 2020): @hydrargyrum thanks for those very useful points. I've added [some improvement suggestions](/hydrargyrum/epistolaire/issues/2) for you. I'll look into how threading is currently implemented in SMS Backup+ to see whether these ideas can be incorporated.

kerem commented

2026-02-26 01:31:08 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 28, 2020):

channelling further discussion into #974

@kurahaupo commented on GitHub (May 28, 2020): channelling further discussion into #974

kerem commented

2026-02-26 01:31:08 +03:00

Author

Owner

@HT-7 commented on GitHub (Mar 10, 2025):

Storing it locally is easier, faster, more straightforward.
No dependency on Google services. No bothering with Google accounts. No Internet connection required.

@HT-7 commented on GitHub (Mar 10, 2025): Storing it locally is easier, faster, more straightforward. No dependency on Google services. No bothering with Google accounts. No Internet connection required. See also: [You don't control your data in the cloud](https://karl-voit.at/cloud)

kerem commented

2026-02-26 01:31:08 +03:00

Author

Owner

@kurahaupo commented on GitHub (Mar 12, 2025):

@HT-7 this issue is closed as a duplicate of #974.

Everyone please add comment there rather than here.

@kurahaupo commented on GitHub (Mar 12, 2025): @HT-7 this issue is closed as a duplicate of #974. Everyone please add comment there rather than here.