How do I take backup of nedb

[narayanchoudhary]

[popod]

I do backups like this:

1. Load the nedb database
2. Query all data from the database
3. Write all the database data into a json file

db.products.find({}, (err, products) => {
  if (err) {
    console.log(err)
    return
  }

  fs.writeFile('products_backup.json', JSON.stringify(products), 'utf8', (err) => {
    if (err) {
      console.log(err)
      return
    }

    console.log('backup file written to disk')
  }
}

Hope this helps.

[mpayne-swm]

create your nedb instance -

var db = new nedb({"filename": "somefilepath", "autoload": true});

(you may need to make sure that there is an empty file there to start with)

do your stuff (inserts, updates, etc.)

db.persistence.compactDatafile();

ta da! Your db is now persisted to "somefilepath"

"back up" the file as per your requirements

(please close this issue if this answers your question)

[fjeddy]

@popod NedB already stores all data in a JSON file, simply copying the NedB datastore file is enough. Your entire operation is literally a complete waste, you're taking a JSON file and converting it into a JSON file :P

[popod]

@fjeddy the NedB file can contain encrypted data if you use afterSerialization and beforeSerialization hooks, so only copy the file should not works as it does not contain JSON data..

[fjeddy]

How so? What am I missing? You're talking about a backup, hence, if you need it, you would restore it to the same system it was taken from.

[JamesMGreene]

Without any afterSerialization/beforeSerialization hooks in effect (e.g. to encrypt/decrypt records), the NeDB file format is best described as Newline-Delimited JSON, though also keeping in mind that it may contain what appear to be "duplicate" records due to its append-only nature if the file was not compacted immediately before the backup copy is made.

It is true that you could just take a copy of the physical file and utilize that as a backup so long as the afterSerialization/beforeSerialization hooks for the app connecting to the database does not change between the time of the backup and the time of restore.

[fjeddy]

It doesn't matter, the user is explicitly asking how he can perform a backup of the NedB database. A simply copy of the NedB file in itself is exactly that, a backup. It could generally be a good idea to run compaction first, to minimize the filesize, but not at all necessary, as the compaction will happen whenever you restore the backup into the system.

afterSerializationand beforeSerialization doesn't change this fact. If you change those functions on a live-database, or within code that later restores a previous version of a NedB database, then the result is the same, the database will contain data that is "invalidated". NedB won't convert data automatically to fit a new serialization on a current, existing, in-use database or in a previous backup. Changing those functions, live or not, will give you the same result.

Simply put; A backup is copying the NedB file. Period. Any other form, is not a pure backup, it's duplicating the database into a different format, which again would require code to restore the database to begin with.

Don't get me wrong, you're all right, in your own ways. But he is specifically asking how he can perform a backup, and you guys are making a bunch of assumptions on why, how and what will happen in the meantime, you're making the matter way more confusing then what it really is.

[mliakos]

I implemented backup & restore functionality in my Electron app and copying the nedb files was the first thing that came into my mind lol. Simple fs.readFile() and fs.copyFile().