delta1037 / notion-export-client Goto Github PK

Traceback (most recent call last):
File "notion_backup_terminal.py", line 9, in
from NotionDump import NotionBackupLogger
ImportError: cannot import name 'NotionBackupLogger' from 'NotionDump' (/opt/homebrew/anaconda3/envs/notion/lib/python3.7/site-packages/NotionDump/init.py)

区分Typora和Obsidian的内容识别方式：

• 文件链接识别方式
• 图片链接识别方式
• CSV文件的加载

将主目录中的数据库挪到database目录中

Notion显示：

导出的显示效果：

想要的效果

导出之后块数据库页面会直接显示在了主页上，而不是跟上面那个一样显示的另一个文档的路径链接

测试页面：https://xmahonix.notion.site/206a4fc146cc47608a76f3325c0ace3f

我每天使用windows定时任务运行备份程序，目前的terminal 版本运行的时候会有一个窗口，因为我是每天定时备份，我希望这个备份程序后台自动运行，不要在前台出现窗口，避免干扰。
我目前自己的解决办法是用了一个VBS脚本，把备份程序后台运行，基本也能满足我的需求，如果terminal 版本能够完善一下这点就更好了，这个备份程序很好用，完美解决notion云端笔记焦虑，给作者点赞👍🏻

Notion备份模版里的备份清单是根据 备份的勾选情况来备份的，如果要每天自动运行备份的话，还有一个问题，就是得 每天勾选一下要备份的页面，如果备份完成，不去掉 备份清单里的 √，是不是就没有这个小麻烦了？

在对测试页面备份时，发现”Database测试“中的inline数据库没有重定位

数据库条目为空时解析出错

hi 譬如我想在docker服务器上运行脚本

已经归档的内容不再获取，即添加filter

备份库的页面，可以按照Last edited time（notion库自带的页面属性）的顺序，从新到旧开始备份

若备份到缓存过的界面，就可以直接停止了，因为之后的页面一定是本地已经备份过的，无需继续访问

这样可以在库的文件较多的情况下，节省备份的时间

Traceback (most recent call last):
File ".\notion_backup_terminal.py", line 9, in
from api.notion_dump import NotionBackup
File "D:\Workspace\python\notion-export-client-main\api\notion_dump.py", line 10, in
import notion_dump
ModuleNotFoundError: No module named 'notion_dump'

大佬，请问我在使用您的工具进行备份时，其他页面和database都备份正常，只有一个database报如下错误，请问该如何解决？

背景：

在使用工具的过程中发现，工具有两大步骤
1 获取所有页面到buffer_file中
2 根据buffer_file中的内容还原为可供阅读的MD文件

第1步是动态更新的，文件若不更新则不会覆盖之前的文件，对存储友好
第2步会完全覆盖之前的所有文件，库中的文件若是多的话，则每次覆盖都会写入大量文件

发现：

第2步其实是多余的，因为一般情况下我们并不需要去观看我们备份好的文件，notion若是访问不出问题我们便不会去看本地备份的文件

建议：

第1步，为备份操作，生成的buffer_file即backup_file
第2步，为还原操作，还原为可供本地观看的格式，一般不会使用
这样做的好处是：备份是动态备份，对存储友好，少了第2步速度也更快

临时解决方案：

目前可以通过将backup_root_path的配置设置为不存在的路径，即可达到相同的效果，不过备份完成后会报一个错

2023年12月5日，使用客户端版本：notion_backup_terminal-v3.0pre，系统：win10；
我有一个页面类似“Notion备份模板”的结构，里面有两个数据库，一个数据里大概有几百个页面，备份多次，使用缓存和不使用缓存都试过，数据库的备份文件显示是空白，一个文件都没有，实际找子页面内容也几乎没有，只有这个数据库里被其他页面引用过的子页面才有内容。
然后我尝试把数据库里的内容挪到Page里，不再使用数据库管理这些子页面，这个问题就神奇地解决了，所以我也没搞懂之前为啥备份失败。
接下来，我尝试复现这个BUG，我在其他数据库里没有复现成功，不知道是不是跟数据库大小有关。